#5341 closed defect (fixed)
debbie failing on raster upgrade from 3.2, 3.1 to 3.4
Reported by: | robe | Owned by: | strk |
---|---|---|---|
Priority: | blocker | Milestone: | PostGIS 3.4.0 |
Component: | build | Version: | master |
Keywords: | Cc: |
Description
Might be related to #5338
https://debbie.postgis.net/job/PostGIS_Regress/24158/consoleFull
07:15:14 psql:../../../raster/test/regress/hooks/hook-before-upgrade-raster.sql:33: NOTICE: Adding coverage tile constraint required for regular blocking 07:15:14 psql:../../../raster/test/regress/hooks/hook-before-upgrade-raster.sql:33: NOTICE: Unable to create coverage raster. Cannot add coverage tile constraint: column "sqlerrm" does not exist (42703) 07:15:14 psql:../../../raster/test/regress/hooks/hook-before-upgrade-raster.sql:33: WARNING: Unable to add constraint: 'regular_blocking'. Skipping 07:15:14 psql:../../../raster/test/regress/hooks/hook-before-upgrade-raster.sql:33: ERROR: None of the constraints specified could be added. Is the schema name, table name or column name incorrect? 07:15:14 CONTEXT: PL/pgSQL function addrasterconstraints(name,name,name,text[]) line 119 at RAISE 07:15:14 ----------------------------------------------------------------------------- 07:15:14 make: *** [../../../regress/runtest.mk:24: check-regress] Error 3 07:15:14 make: Leaving directory '/var/lib/jenkins/workspace/postgis/branches/3.4/raster/test/regress' 07:15:14 FAIL: postgis_raster script-based upgrade unpackaged3.2--:auto 07:15:14 Testing postgis_raster script-based upgrade unpackaged3.3--:auto 07:15:14 make: Entering directory '/var/lib/jenkins/workspace/postgis/branches/3.4/raster/test/regress' 07:15:14 RUNTESTFLAGS: -v --upgrade-path=unpackaged3.3--:auto -v --raster
Change History (24)
comment:1 by , 21 months ago
comment:2 by , 21 months ago
She's not failing at the moment because I think she had a postgresql build since which wiped out all installed versions.
comment:3 by , 21 months ago
I changed her to not build the stable branches so frequently to allow old postgis installs to build up so we have many more postgis versions to upgrade from. I expect this issue to come back soon, but we'll see.
comment:4 by , 21 months ago
Summary: | debbie failing on raster upgrade from 3.2 to 3.4 → debbie failing on raster upgrade from 3.2, 3.1 to 3.4 |
---|
comment:5 by , 21 months ago
Component: | raster → build/upgrade/install |
---|---|
Owner: | changed from | to
comment:6 by , 20 months ago
The error column "sqlerrm" does not exist (42703)
suggests a bug in the version of PostGIS that your test ends up loading, which for an upgrade-path of unpackaged3.3--:auto
is whatever version is in ${PG_SHAREDIR}/contrib/postgis-3.3
Now, with a quick look at postgis-3.3/rtpostgis.sql (for 3.3.3dev) I found this snippet which seems suspicious:
-- rasterize extent BEGIN _covrast := ST_AsRaster(_covextent, _scalex, _scaley, '8BUI', 1, 0, NULL, NULL, _skewx, _skewy); IF _covrast IS NULL THEN RAISE NOTICE 'Unable to create coverage raster. Cannot add coverage tile constraint: % (%)', SQLERRM, SQLSTATE; RETURN FALSE; END IF;
IN this case the SQLERRM is probably not set because the code is NOT in an exception handling block. The problem should then arise when the ST_AsRaster call performed by _add_raster_constraint_coverage_tile returns NULL
comment:7 by , 20 months ago
I'm surprised we don't see this error in ALL bots, but maybe Debbie is the only one testing upgrades from yet-to-be-released PostGIS old versions ?
comment:8 by , 20 months ago
The bug was introduced by commit [97ba109a541870b526667431397bc2666bca452e/git] (July 2014!)
comment:10 by , 20 months ago
I'm trying to reproduce this locally but don't seem to be able to. The problem should be triggered by ST_Metadata returning NULL for some of the parameters passed to ST_AsRaster, which would then return NULL. If that's the case the current code would raise a DEBUG. Any chance you have those DEBUG logs activated in debbie's log ?
comment:15 by , 20 months ago
I've fixed the reference to unexisting variable in all branches from 3.4 back to 3.0 but I'm not closing this ticket because even without referencing the missing variable, given the conditions that seem to have been detected by Debbie you should still see error:
ERROR: None of the constraints specified could be added.
It would be nice if you could re-produce the issue.
comment:16 by , 20 months ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I'm closing as I believe the problem was fixed. Debbie is trouble in other ways at the moment so it's not worth waiting for her to re-produce this issue. Eventually it can be re-opened.
comment:17 by , 20 months ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
This is still failing on unpackaged to packaged and packaged to unpackaged.
comment:19 by , 20 months ago
I reopened because of the failures happening on PG14
https://debbie.postgis.net/job/PostGIS_Regress/24560/consoleFull
6:48:19 psql:../../../raster/test/regress/hooks/hook-before-upgrade-raster.sql:33: NOTICE: Adding coverage tile constraint required for regular blocking 16:48:19 psql:../../../raster/test/regress/hooks/hook-before-upgrade-raster.sql:33: NOTICE: Unable to create coverage raster: ST_AsRaster returned NULL. 16:48:19 psql:../../../raster/test/regress/hooks/hook-before-upgrade-raster.sql:33: WARNING: Unable to add constraint: 'regular_blocking'. Skipping 16:48:19 psql:../../../raster/test/regress/hooks/hook-before-upgrade-raster.sql:33: ERROR: None of the constraints specified could be added. Is the schema name, table name or column name incorrect? 16:48:19 CONTEXT: PL/pgSQL function addrasterconstraints(name,name,name,text[]) line 119 at RAISE 16:48:19 ----------------------------------------------------------------------------- 16:48:19 make: *** [../../../regress/runtest.mk:24: check-regress] Error 3 16:48:19 make: Leaving directory '/var/lib/jenkins/workspace/postgis/branches/3.4/raster/test/regress' 16:48:19 FAIL: postgis_raster extension upgrade unpackaged3.1--3.4.0dev 16:48:19 Testing postgis_raster extension upgrade unpackaged3.2--3.4.0dev 16:48:19 make: Entering directory '/var/lib/jenkins/workspace/postgis/branches/3.4/raster/test/regress' 16:48:19 RUNTESTFLAGS: -v --extension --upgrade-path=unpackaged3.2--3.4.0dev -v --raster 16:48:19 RUNTESTFLAGS_INTERNAL: --before-upgrade-script ../../../raster/test/regress/hooks/hook-before-upgrade-raster.sql --after-upgrade-script ../../../raster/test/regress/hooks/hook-after-upgrade-raster.sql
The error is different from before but still same area of failure.
Seems to be only an issue going from 3.1 -> 3.4 or 3.2-- 3.4 . 3.3--> 3.4 is fine.
comment:20 by , 20 months ago
It could be addrasterconstraints() behaviour changed in 3.3 and our use of it from the before-upgrade-raster hook is incompatible. The idea of that call before upgrade was to test the fix for #5338
comment:21 by , 20 months ago
The manual doesn't say anything about behavioural changes: https://postgis.net/docs/manual-3.3/RT_AddRasterConstraints.html
comment:22 by , 20 months ago
Note I still cannot reproduce locally:
../regress/run_test.pl -v --extension --raster --upgrade-path unpackaged3.2--:auto --before-upgrade-script ../raster/test/regress/hooks/hook-before-upgrade-raster.sql --after-upgrade-script ../raster/test/regress/hooks/hook-after-upgrade-raster.sql ../raster/test/regress/box3d.sql
Works fine for me, and /tmp/pgis_reg/regress_log nicely says:
psql:../raster/test/regress/hooks/hook-before-upgrade-raster.sql:33: NOTICE: Adding coverage tile constraint required for regular blocking psql:../raster/test/regress/hooks/hook-before-upgrade-raster.sql:33: NOTICE: Adding spatially unique constraint required for regular blocking addrasterconstraints ---------------------- t (1 row)
What would the possible reasons why ST_AsRaster would return NULL in Debbie ?
comment:23 by , 17 months ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
What's interesting is woodie is doing the same upgrade tests and is not failing. So perhaps something wrong with my backports to older versions.
Only difference in theory between woodie's
is that debbie would be upgrading from a not yet released version of postgis 3.3 which might have the new patch.