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"  (Albert Ullrich <aullrich@blackducksoftware.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #5622: Query failed: server closed the connection unexpectedly
Следующее
От: Martin Pitt
Дата:
Сообщение: Re: libpq: system-wide root.crt