From: | Albert Ullrich <aullrich(at)blackducksoftware(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #5626: Parallel pg_restore fails with "tuple concurrently updated" |
Date: | 2010-08-19 20:47:46 |
Message-ID: | C89310B2.1436E%aullrich@blackducksoftware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
Where would the reordering happen?
Thanks,
A. Ullrich
On 8/19/10 3:59 PM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
"Albert Ullrich" <aullrich(at)blackducksoftware(dot)com> writes:
> Description: Parallel pg_restore fails with "tuple concurrently
> updated"
> pg_restore -e -v -j 4 -Fc -L /tmp/fp_basic.toc -d fp_basic
> /tmp/fp_basic.dump
Apparently you've used the -L option to reorder the dump objects in a way
that won't work with parallel restore. On the whole I don't recommend
trying to use -L with parallel restore at all, but if you must do it,
it's your responsibility to choose a safe order. Basically, you had
better keep all the PRE_DATA objects ahead of the DATA objects, and
those ahead of POST_DATA objects.
Did you have a specific reason for not wanting to let parallel restore
choose the restore order for itself?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Martin Pitt | 2010-08-19 21:11:12 | Re: libpq: system-wide root.crt |
Previous Message | Tom Lane | 2010-08-19 19:59:02 | Re: BUG #5626: Parallel pg_restore fails with "tuple concurrently updated" |