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

From Tom Lane
Subject Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables
Date
Msg-id 21450.1249525780@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables  (Andrew Dunstan <andrew@dunslane.net>)
Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables  (Dimitri Fontaine <dfontaine@hi-media.com>)
Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
List pgsql-hackers
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 ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables
Next
From: Andrew Dunstan
Date:
Subject: Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables