Re: heap_create with OID?

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Philip Warner <pjw(at)rhyme(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: heap_create with OID?
Date: 2000-07-06 14:16:28
Message-ID: 200007061416.KAA06804@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > The only real problem (and this is in pg_dump as well), is if a table is
> > dumped with OIDs and the OIDs conflict with automatically generated ones
> > for the schema. Although this may not be an issue: how unique are OIDs,
> > anyway? Will corruption of any kind occur in the above case (even with the
> > old pg_dump)?
>
> In theory OIDs are unique (within one database anyway). There are a
> couple of ways that theory can fail:
>
> 1. User-supplied OIDs (via COPY WITH OIDs) might conflict.
>
> 2. Run the system long enough, the OID counter will wrap around and
> start generating already-used numbers.

Seems we should throw an error on rollover, or at least jump from 0 to
17k to skip the system oid's. That zero oid is going to cause a
problem, perhaps. Of course, it is has never happened, but maybe we
should do it for people's sanity.

>
> The next question is what happens if we do have duplicate OIDs. AFAIK,
> if the duplicate OIDs are for different kinds of entities (eg, rows in
> different tables) the answer is "no problem". Duplicate OIDs for, say,
> two tables would be disastrous --- but the unique index on pg_class.oid
> should prevent you from creating duplicates. I *think* that 7.0 has
> unique indexes on every system table where it's important to prevent
> duplicate OIDs. (If not, it's an easily corrected omission; anyone want
> to run through the tables and double-check?)

It sure does, or at least ones that are used by the cache.

> OIDs aren't magic, they're just another number. The system depends on
> the assumption that OIDs are unique keys for certain system tables, and
> it enforces (or should enforce) this assumption. Applications might
> depend on the assumption that OIDs are unique keys for their own tables;
> if so they can and should enforce that assumption with unique indexes.
> But there's no hidden mechanism that will make the system go belly-up
> just because there are identical OIDs floating around.
>
> regards, tom lane
>
> PS: I believe the "comment" support will misbehave if there are
> duplicate OIDs in different system tables, since it assumes that an OID
> is sufficient to identify any database object regardless of type.
> But the comment stuff is not exactly mission-critical...

Agreed.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ron Peterson 2000-07-06 14:19:41 Re: proposed improvements to PostgreSQL license
Previous Message Tom Lane 2000-07-06 13:58:02 Re: oidvector problem, latest version- has read other oidvector notes