Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

Next:From: Albert UllrichDate: 2010-08-19 20:47:46
Subject: Re: BUG #5626: Parallel pg_restore fails with "tuple concurrently updated"
Previous:From: Tom LaneDate: 2010-08-19 15:19:58
Subject: Re: BUG #5622: Query failed: server closed the connection unexpectedly

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group