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

Re: BUG #5626: Parallel pg_restore fails with "tupleconcurrently updated"

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Albert Ullrich <aullrich(at)blackducksoftware(dot)com>,"pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #5626: Parallel pg_restore fails with "tupleconcurrently updated"
Date: 2010-08-20 17:43:40
Message-ID: 20100820174340.GI26232@tamriel.snowman.net (view raw or flat)
Thread:
Lists: pgsql-bugs
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Mph ... removing the public schema from the restore list is problematic,
> because you've got a lot of stuff *in* the public schema, and of course
> all that stuff depends on the public schema entry.  Normally this
> doesn't bother pg_restore because it just blindly restores in the order
> you tell it, without paying much attention to the dependency entries.

The problem here, to some extent, is that 'public' is where everyone
dumps their favorite contrib functions (classic example here being
PostGIS).  I just ran into this during an 8.3->8.4 upgrade yesterday.  I
installed the new PostGIS on 8.4 and didn't need/want the old PostGIS to
be copied over from the 8.3 instance.  In that case I wasn't trying
parallel restore, but there are certainly cases where I'll want to..

> We should probably try to make pg_restore smarter about this case,

Yes, definitely.  I don't have an immediate solution though,
unfortunately.  Would be kind of neat if pg_restore could connect to the
NEW database and determine if certain things exist which are needed
dependencies...  That's a whole lot of rather complex work though.

	Thanks,

		Stephen

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2010-08-20 18:19:17
Subject: Re: BUG #5626: Parallel pg_restore fails with "tuple concurrently updated"
Previous:From: Tom LaneDate: 2010-08-20 17:24:38
Subject: Re: BUG #5626: Parallel pg_restore fails with "tuple concurrently updated"

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