| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Albert Ullrich" <aullrich(at)blackducksoftware(dot)com> |
| Cc: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #5626: Parallel pg_restore fails with "tuple concurrently updated" |
| Date: | 2010-08-19 19:59:02 |
| Message-ID: | 26637.1282247942@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
"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 | Albert Ullrich | 2010-08-19 20:47:46 | Re: BUG #5626: Parallel pg_restore fails with "tuple concurrently updated" |
| Previous Message | Tom Lane | 2010-08-19 15:19:58 | Re: BUG #5622: Query failed: server closed the connection unexpectedly |