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

I followed your advise, Tom and reworked the way we do dumps and restores to remove the requirement for having TOCs.

So far the restores executed flawlessly and I am grateful for having this feature available to us! Huge time savings!

Thanks!

Albert

On 8/20/10 1:24 PM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

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

A. Ullrich
Director, Quality Assurance and Infrastructure
Black Duck Software, Inc.

aullrich(at)blackducksoftware(dot)com
T +1.781.810.2092
C +1.781.405.0780
F +1.781.891.5145
http://www.blackducksoftware.com