Proposed patch for preventing OID collisions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-patches(at)postgreSQL(dot)org
Subject: Proposed patch for preventing OID collisions
Date: 2005-08-10 22:16:56
Message-ID: 15747.1123712216@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Attached is a reasonably complete working-out of my earlier proposal to
prevent OID collisions by probing catalogs' OID indexes and advancing to
the next OID whenever there is a duplicate. The code is driven by the
existence of a unique index, and so it is possible for users to take
advantage of the feature too:

create table foo(...) with oids;
create unique index foo_oid on foo(oid);

I'm not sure if we really want to document that though, as the
implementation will perform poorly when there are long runs of
consecutive OIDs in the table. This is relatively unlikely in the
system catalogs but seems quite probable in a user table.

The patch also removes CheckMaxObjectId, which seems no longer needed.
If we commit it, we should remove the code in pg_dump that tries to
set the OID counter, since that'd be dead code; but I didn't include
that change in this patch. Documentation updates are lacking too.

In principle I think this could be back-patched as far as 7.2, since
RelationGetIndexList exists that far back, but of course it needs a
good deal of testing before we even think about that. (There are a
couple of aspects that depend on the recent changes to have fixed,
preassigned OIDs for system catalogs, and we'd have to tweak those
areas to make a back-patch.)

Comments?

regards, tom lane

Attachment Content-Type Size
unique_oids.patch.gz application/octet-stream 12.1 KB

Browse pgsql-patches by date

  From Date Subject
Next Message Qingqing Zhou 2005-08-11 02:00:10 Re: Fix oversight in pts_error_callback()
Previous Message Bruce Momjian 2005-08-10 21:29:37 Re: (was COPY FROM) performance improvements