User mover error with rasters + overlays

STR:

• Import a raster into CARTO, and create some overviews (CARTO automatically creates one for level 1)
• Try to move the user

The check _overview_constraint for the overview can fail. The issues is that with parallel execution, it is possible that the overlay data will be imported before the raster itself, and this check will fail.

Workarounds:

• Run pg_restore in order (remove -j X) <-- this one doesn’t always work.
• ~Disable the check before export, reeenable after import. e.g~ (DON’T DO THIS, see further comment about using a pg_restore index):

SELECT DropOverviewConstraints('schema'::name, 'o_16_tablename'::name, 'the_raster_webmercator'::name);
SELECT AddOverviewConstraints('schema'::name, 'o_16_tablename'::name, 'the_raster_webmercator'::name, 'schema'::name, 'tablename'::name, 'the_raster_webmercator'::name, 16);

As this is an uncommon case, I would suggest making -j parametrizable and just passing that parameter when the raster situation is detected. Slower import but it works.

cc @juanignaciosl

[juanignaciosl]

Disclaimer: read the full comment before doing anything based on this.

For future reference, the -j1 hack didn’t work at CartoDB/tech-ops/issues/292. The error (check the comment) was weird because the constraint didn’t appear at the index file, so I chose a different manual alternative.

This would’ve been the “normal manual” approach:

1. Given the exported dump, run pg_restore with -l so it outputs an index. That output must be redirected to a file. Example: pg_restore -l /tmp/user_export_<id>/data/org_<id>.dump > /tmp/org.dump.index
2. Comment (with ;) the lines with overview constraints.
3. Run the import (the “rake import”, not the pg_restore) with -L <patched index file> so it skips the overviews.
4. Add the missing constraints.

Nevertheless, I had to do this:

1. Given the exported dump, I run pg_restore with -l so it outputs an index. That output must be redirected to a file. Example: pg_restore -l /tmp/user_export_<id>/data/org_<id>.dump > /tmp/org.dump.index
2. I commented (with ;) the lines with TABLE DATA from overviews (lines containing TABLE DATA on an overview table, which are the ones that begin with o_).
3. Then, I patched services/user-mover/import_user.rb, adding -L /tmp/org.dump.index to pg_restore command.
4. Then I run the import so it skips the overview data tables.
5. Aftwerwards, I opened /tmp/org.dump.index, deleted everything but the commented lines and uncommented those.
6. Then I run pg_restore (you have to download and unzip the S3 file again, using the dump path for this comment:

/tmp/user_imports$ /usr/lib/postgresql/9.5/bin/pg_restore -e --verbose --disable-triggers -L /tmp/org.dump.index -Fc /tmp/user_imports/data/org_<id>.dump -U postgres -h <IP> -p 5432 -d cartodb_user_<id>_db

This also failed, same error 🎉

So, let’s drop the constraint and copy the data:

SELECT DropOverviewConstraints('<schema>'::name, 'o_16_<table_name>'::name, 'the_raster_webmercator'::name);
SELECT DropOverviewConstraints('<schema>'::name, 'o_2_<table_name>'::name, 'the_raster_webmercator'::name);
SELECT DropOverviewConstraints('<schema>'::name, 'o_4_<table_name>'::name, 'the_raster_webmercator'::name);
SELECT DropOverviewConstraints('<schema>'::name, 'o_8_<table_name>'::name, 'the_raster_webmercator'::name);

Uncomment the lines of the index and run again so it just imports the data tables:

/tmp/user_imports$ /usr/lib/postgresql/9.5/bin/pg_restore -e --verbose --disable-triggers -L /tmp/org.dump.index -Fc /tmp/user_imports/data/org_<id>.dump -U postgres -h <IP> -p 5432 -d cartodb_user_<id>_db

Recreate the overviews:

SELECT AddOverviewConstraints('<schema>'::name, 'o_16_<table_name>'::name, 'the_raster_webmercator'::name, '<schema>'::name, '<table_name>'::name, 'the_raster_webmercator'::name, 16);
SELECT AddOverviewConstraints('<schema>'::name, 'o_2_<table_name>'::name, 'the_raster_webmercator'::name, '<schema>'::name, '<table_name>'::name, 'the_raster_webmercator'::name, 2);
SELECT AddOverviewConstraints('<schema>'::name, 'o_4_<table_name>'::name, 'the_raster_webmercator'::name, '<schema>'::name, '<table_name>'::name, 'the_raster_webmercator'::name, 4);
SELECT AddOverviewConstraints('<schema>'::name, 'o_8_<table_name>'::name, 'the_raster_webmercator'::name, '<schema>'::name, '<table_name>'::name, 'the_raster_webmercator'::name, 8);

This approach is better than dropping + recreating the constraints because it doesn’t require touching the source DB. Nevertheless, in this case we could’ve considered doing that instead, because it’s really strange that the index didn’t contain the failing constraints.

[javitonino]

It’s not exactly a trick, but it is not ideal either. I’d be more comfortable adding it to the json generated by user-mover than to the migration models.

Anyway, I just realised that we can properly detect it on import, by checking if the dump file has an _overview_constraint in it (pg_restore -l and some grepping should do it). So no, you are not adding more fields to my lean models! Stop trying to convince me! 😛