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

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: Raw Message | Whole Thread | 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

In response to

Responses

Browse pgsql-bugs by date

  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