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

* 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