[postgis-users] Accessing lots of missing outdb/offline rasters appear to cause PostgreSQL to crash

Bborie Park dustymugs at gmail.com
Mon Mar 31 20:48:29 PDT 2014


So, you were hitting two separate problems. Can we see the query that
you're actually trying to run? The assert itself indicates that somehow
rt_raster_from_band received a raster from which bands are to be extracted
but the raster is NULL.

You've going to have to examine your query and the dataset the query is
being run upon.

Without knowing more about your query and your dataset, I can't say what
exactly is causing rt_raster_from_band to receive a NULL raster.

I'll do some poking to see how that function could be receiving a NULL
raster.

-bborie


On Mon, Mar 31, 2014 at 8:01 PM, Robert Nix <robert at urban4m.com> wrote:

> Upgraded:
>
> POSTGIS="2.1.2 r12389" GEOS="3.3.8-CAPI-1.7.8" PROJ="Rel. 4.8.0, 6 March
> 2012" GDAL="GDAL 1.10.0, released 2013/04/24" LIBXML="2.8.0" (core procs
> from "2.1.1 r12113" need upgrade) TOPOLOGY (topology procs from "2.1.1
> r12113" need upgrade) RASTER (raster procs from "2.1.1 r12113" need upgrade)
>
>
> Unfortunately, *the problem persists* though the scenario is slightly
> different. Specifically, it appears to be unrelated to inaccessible offline
> rasters since the issue is now occurring even while all offline rasters are
> accessible. But it may be due to any SQL exception occurring during the
> processing of SQL that contains raster functions. In other words, I am
> doing an insert that contains calls to functions that execute SQL like that
> in my original post. In some cases, an exception (duplicate key) is
> occurring and almost immediately following that error is the rt_raster_from_band:
> Assertion. And it's consistent. If the duplicate key error occurs, the
> assertion follows. The only other times i see the assertion seems to be
> related to recovery attempts.
>
> If the assertion occurs more than a few dozen times, the database goes
> into a permanent "recovery mode" outputting nothing else to the log except
> the recovery message several times a second until i can stop the postgresql
> service.
>
>
>
> On Monday, March 31, 2014 12:44:00 PM UTC-4, Robert Nix wrote:
>>
>> After 1001 of these errors:
>>
>> 2014-03-31 15:50:51 UTC ERROR:  rt_band_load_offline_data: Cannot open
>> offline raster: /...
>>
>>
>> I get:
>>
>> SELECT: rt_api.c:8659: rt_raster_from_band: Assertion `((void *)0) !=
>> raster' failed.
>> 2014-03-31 15:50:52 UTC LOG:  server process (PID 8385) was terminated by
>> signal 6: Aborted
>>
>>
>> Eventually resulting in:
>>
>> 2014-03-31 15:50:52 UTC FATAL:  the database system is in recovery mode
>>
>>
>> Requiring bouncing the postgres service.
>>
>> I'm not sure if this is an issue with PostGIS or PostgreSQL itself.
>>
>> I'm accessing the rasters from within a sql function, essentially:
>>
>> st_setbandnodatavalue(
>>   st_snaptogrid(
>>     st_setsrid(_rast,4326),
>>     gridx:=st_upperleftx(_rast),
>>     gridy:=st_upperlefty(_rast)
>>   ),
>>   0.0
>> )
>>
>>
>>
> _______________________________________________
> postgis-users mailing list
> postgis-users at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20140331/91dfd3f9/attachment.html>


More information about the postgis-users mailing list