Opened 10 years ago
Closed 10 years ago
#2849 closed defect (duplicate)
winnie crashing on PostGIS 2.1 raster
Reported by: | robe | Owned by: | robe |
---|---|---|---|
Priority: | blocker | Milestone: | PostGIS 2.1.4 |
Component: | QA/buildbots | Version: | 2.1.x |
Keywords: | Cc: |
Description
I've been really bad about paying attention to winnie's screams -- I took a gander and she's been unhappy with 2.1 since June 27th.
This is the last error:
permitted_gdal_drivers .. failed (diff expected obtained: /projects/postgis/tmp/2.1.4dev_pg9.2_geos3.4.2_gdal1.10.0w64/test_68_diff) ----------------------------------------------------------------------------- --- permitted_gdal_drivers_expected 2014-05-04 12:24:55 -0400 +++ /projects/postgis/tmp/2.1.4dev_pg9.2_geos3.4.2_gdal1.10.0w64/test_68_out 2014-07-18 11:46:55 -0400 @@ -1,10 +1,6 @@ DO 4326 -ERROR: RASTER_fromGDALRaster: Could not open bytea with GDAL. Check that the bytea is of a GDAL supported format -ERROR: rt_raster_load_offline_data: Access to offline bands disabled -ERROR: rt_raster_load_offline_data: Access to offline bands disabled -4326 -4326 -ERROR: rt_raster_load_offline_data: Access to offline bands disabled -ERROR: rt_raster_load_offline_data: Access to offline bands disabled -4326 +server closed the connection unexpectedly + This probably means the server terminated abnormally + before or while processing the request. +connection to server was lost ----------------------------------------------------------------------------- tickets .. failed (diff expected obtained: /projects/postgis/tmp/2.1.4dev_pg9.2_geos3.4.2_gdal1.10.0w64/test_69_diff) ----------------------------------------------------------------------------- --- tickets_expected 2013-11-27 11:24:51 -0500 +++ /projects/postgis/tmp/2.1.4dev_pg9.2_geos3.4.2_gdal1.10.0w64/test_69_out 2014-07-18 11:46:55 -0400 @@ -1 +1 @@ -#1485|0 +psql: FATAL: the database system is in recovery mode ----------------------------------------------------------------------------- loader/Basic ... failed ( test: running raster2pgsql output: /projects/postgis/tmp/2.1.4dev_pg9.2_geos3.4.2_gdal1.10.0w64/loader.err) ----------------------------------------------------------------------------- psql: FATAL: the database system is in recovery mode ----------------------------------------------------------------------------- loader/BasicCopy ... failed ( test: running raster2pgsql output: /projects/postgis/tmp/2.1.4dev_pg9.2_geos3.4.2_gdal1.10.0w64/loader.err) ----------------------------------------------------------------------------- psql: FATAL: the database system is in recovery mode ----------------------------------------------------------------------------- loader/BasicFilename .... ok clean .. ok uninstall . /projects/postgis/branches/2.1/regress/00-regress-install/share/contrib/postgis/uninstall_rtpostgis.sql /projects/postgis/branches/2.1/regress/00-regress-install/share/contrib/postgis/uninstall_postgis.sql . ok (4061 )
That is from 9.2 64-bit output. Interestingly I'm not seeing same issue on PostGIS 2.2. It's quite possible I'm not testing 2.2/9.2 mix since I was deliberating packaging a PostGIS 2.2 release for 9.2.
Anyrate I need to investigate more if its a change in GDAL / PostGIS or something else causing this issue
Change History (5)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
Hmmmm. Might be something to do with the code for digesting env variables.
PostgreSQL 9.2.8 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.7.1, 64-bit Postgis 2.1.4dev - r12802 - 2014-07-21 14:38:09 scripts 2.1.4dev r12802 raster scripts 2.1.4dev r12802 GEOS: 3.5.0dev-CAPI-1.9.0 r3963 PROJ: Rel. 4.8.0, 6 March 2012 GDAL: GDAL 2.0.0dev, released 2014/04/16
I'm not seeing the same in linux...
comment:3 by , 10 years ago
though that hasn't changed since we released 2.1.3 has it? Was fine with 2.1.3 release or did we add new tests?
comment:5 by , 10 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
duplicate -- already fixed in #2897
actually think something wrong with 2.2 as well for 92 (though that one is failing db start so potentially different issue). That one does raise a red flag since its done as an after 2.2 success downstream job.