Issue with user mover and raster data
See original GitHub issueDuring #4960, we discovered the following issue withg pg_restore
and rasters: http://trac.osgeo.org/postgis/ticket/2485
Note: this error looks like this for us:
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 4715; 0 697887 TABLE DATA o_2_q37866 cartodb_user_9be99c95-2fa3-4c2a-9e64-60282a40874d
pg_restore: [archiver (db)] COPY failed for table "o_2_q37866": ERROR: function st_bandmetadata(public.raster, integer[]) does not exist
LINE 1: ...(round(nodatavalue::numeric, 10))::numeric[] FROM st_bandmet...
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
It was solved in postgis 2.3.0 (changelog), but in postgis 2.2.2 (changelog) there is a hacky script to fix this, see section 10.1 in http://postgis.net/docs/manual-2.2/RT_FAQ.html#faq_raster_data_not_restore- #3426, failing POINT EMPTY tests on fun architectures
For the migration, I ran the following script after creating the database and extension, but before importing the data:
ALTER FUNCTION _raster_constraint_pixel_types(raster) SET search_path=pg_catalog,public,postgis;
ALTER FUNCTION _raster_constraint_nodata_values(raster) SET search_path=pg_catalog,public,postgis;
ALTER FUNCTION _raster_constraint_out_db(raster) SET search_path=pg_catalog,public,postgis;
ALTER FUNCTION _raster_constraint_info_regular_blocking(name, name, name) SET search_path=pg_catalog,public,postgis;
ALTER FUNCTION _overview_constraint(raster, integer, name, name, name) SET search_path=pg_catalog,public,postgis;
Although this works, it would be great if we could use the official script.
In order to be able to run that script “after creating the database and extension, but before importing the data” you can add a sleep(10)
between those steps (after line 513).
Issue Analytics
- State:
- Created 6 years ago
- Comments:5 (4 by maintainers)
Top GitHub Comments
I wrote https://github.com/CartoDB/cartodb-management/issues/5080 as a more generic ticket for user mover problems, since it turns our many of them are related.
This was already solved