Re: OID wraparound: summary and proposal

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: pgsql-hackers(at)postgresql(dot)org
Subject: Re: OID wraparound: summary and proposal
Date: 2001-08-02 01:50:52
Message-ID: 200108020150.f721oqg01036@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> >> For input, I see no downside to just
> >> ignoring the incoming OIDs. For output, I can see three reasonable
> >> possibilities:
> >>
> >> A. Pretend WITH OIDS wasn't mentioned. This might seem to be
> >> "do the right thing", but a rather strong objection is that the
> >> app will not get back the data it was expecting.
> >>
> >> B. Return NULLs or 0s for the OIDs column.
> >>
> >> C. Raise an error and refuse to do the copy at all.
> >>
> >> C is probably the most conservative answer.
>
> > If we fail on load, we should fail on dump. Why not fail on COPY WITH
> > OIDS on a non-oid table?
>
> I'm confused --- I was proposing that we *not* fail on load. What's the
> point of failing on load?

I meant to say we should fail on dump _and_ load. If we don't we are
throwing away the oid's they are loading because though the table has no
oid column. Seems like something that should fail.

>
> >> How so? pg_description is broken anyway given that we don't enforce OID
> >> uniqueness across system catalogs. Also, in the future we could
>
> > We have a script to detect them and the oid counter it unique. In what
> > way do we not enforce it.
>
> In a running system, once the OID counter wraps around there's no
> guarantee that you won't have duplicate OIDs in different system
> tables. The only enforcement mechanism we have is the unique indexes,
> and those will only check per-table. However, that's fine --- it's
> as much as we need. For everything except pg_description, that is.
> Since pg_description currently makes an unchecked and uncheckable
> assumption of global uniqueness of OIDs, it's broken.

If you consider random table creation failures acceptible. In oid
wraparound, whether pg_description could point to two rows with the same
oid is the smallest part of our problem. I think the whole idea we can
run reliably with an oid wraparound is questionable.

--
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

Browse pgsql-hackers by date

  From Date Subject
Next Message G. Anthony Reina 2001-08-02 01:52:54 Re: Is there a way to drop and restore an index?
Previous Message Bruce Momjian 2001-08-02 01:45:15 Re: Revised Patch to allow multiple table locks in "Unison"