Re: BUG #5626: Parallel pg_restore fails with "tuple concurrently updated"
| От | Tom Lane |
|---|---|
| Тема | Re: BUG #5626: Parallel pg_restore fails with "tuple concurrently updated" |
| Дата | |
| Msg-id | 26637.1282247942@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | BUG #5626: Parallel pg_restore fails with "tuple concurrently updated" ("Albert Ullrich" <aullrich@blackducksoftware.com>) |
| Ответы |
Re: BUG #5626: Parallel pg_restore fails with "tuple
concurrently updated"
|
| Список | pgsql-bugs |
"Albert Ullrich" <aullrich@blackducksoftware.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
В списке pgsql-bugs по дате отправления: