Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> > 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 ...
> >
> >
> >
>
> Is there any danger that an oid used in, say, pg_enum in the old version
> will be used in the catalog bootstrap in the new version?
No because the catalog bootstrap oids are all lower than
FirstNormalObjectId. The _big_ problem is the creation of pg_type oids
while other things are being created, e.g. you say to create an object
of fixed oid 123 and the array is created as 124, and later you need to
use 124 as a fixed oid. We will need to assign _every_ pg_type oid from
pg_dump so we are sure there are not some assigned that we will need
later.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
