Re: BUG #5626: Parallel pg_restore fails with "tuple concurrently updated"

Albert Ullrich <aullrich(at)blackducksoftware(dot)com> writes:
> We run essentially the following commands to create the table of contents in order to prevent pg_restore from failing:
> pg_restore -l database.dump | \
> eval fgrep -v -e "' SCHEMA - public '" \
> -e "' COMMENT - SCHEMA public '" \
> -e "' PROCEDURAL LANGUAGE - plpgsql'" database.toc

Mph ... removing the public schema from the restore list is problematic,
because you've got a lot of stuff *in* the public schema, and of course
all that stuff depends on the public schema entry. Normally this
doesn't bother pg_restore because it just blindly restores in the order
you tell it, without paying much attention to the dependency entries.
However, in parallel restore mode it does believe the dependencies,
and the fact that you've got lots of entries that depend on something
not to be restored screws it up.

We should probably try to make pg_restore smarter about this case,
but for the moment my advice remains: don't use -L with parallel
restore. It appears to me that you're trying to avoid running
pg_restore as superuser, which no doubt seems a bit safer, but
it's not a terribly well-tested path.

regards, tom lane