Re: BUG #5626: Parallel pg_restore fails with "tuple concurrently updated" - Mailing list pgsql-bugs

From Stephen Frost
Subject Re: BUG #5626: Parallel pg_restore fails with "tuple concurrently updated"
Date
Msg-id 20100820174340.GI26232@tamriel.snowman.net
Whole thread Raw
In response to Re: BUG #5626: Parallel pg_restore fails with "tuple concurrently updated"  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #5626: Parallel pg_restore fails with "tuple concurrently updated"  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
* Tom Lane (tgl@sss.pgh.pa.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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #5626: Parallel pg_restore fails with "tuple concurrently updated"
Next
From: Tom Lane
Date:
Subject: Re: BUG #5626: Parallel pg_restore fails with "tuple concurrently updated"