Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables
Date
Msg-id 4A7C3526.20000@sun.com
Whole thread Raw
In response to Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Dne  6.08.09 04:29, Tom Lane napsal(a):
> Andrew Dunstan <andrew@dunslane.net> writes:
>> preventing a clash might be fairly difficult.
> 
> Yeah, I was just thinking about that.  The easiest way to avoid
> collisions would be to make pg_dump (in --binary-upgrade mode)
> responsible for being sure that *every* new pg_type and pg_class row
> OID matches what it was in the old DB.  We could stop doing that
> once we have all the user tables in place --- I don't believe it's
> necessary to preserve the OIDs of user indexes.  But we need to
> preserve toast table OIDs, and toast table index OIDs too if those
> are created at the same time they are now (else we risk one of them
> colliding with a toast table OID we want to create later).
> 
> Oh, and pg_enum rows too.
> 
> It seems doable, but we're certainly not going to back-patch
> any such thing into 8.4 ...

Another way is to use direct catalog update which I presented on PgCon. 
I think it should be easy to finish it (2-3weeks) for 8.4 - needs small 
extension of bootstrap. And of course testing, testing ...

Also to remove oid in catalog and replace it with standard column (type 
can be oid) should make things easier. But it is for 8.5.

I will send a code on Monday for people who wants to look on it.
Zdenek


pgsql-hackers by date:

Previous
From: Boszormenyi Zoltan
Date:
Subject: Re: Split-up ECPG patches
Next
From: Tom Lane
Date:
Subject: Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock