Re: Thought on OIDs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Patrik Kudo <kudo(at)partitur(dot)se>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Thought on OIDs
Date: 2001-03-01 15:59:43
Message-ID: 21287.983462383@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Patrik Kudo <kudo(at)partitur(dot)se> writes:
> A thought just hit me and I got a bit worried... If OIDs are "globaly"
> unique and I have a very high data-throughput on my database, i.e. I do a
> lot of inserts and deletes, is it then possible to "run out" of OIDs? If
> this can occur, will it cause any problems?

The OID counter will eventually wrap around, which means that OIDs are
not necessarily as unique as all that. This need not bother you unless
your application logic assumes that it can use OID as a unique key for a
table. If so, I recommend making sure that the OIDs in a particular
table are indeed unique, by creating a unique index on oid. (This might
lead to occasional insertion failures, which can simply be retried until
they succeed.) Avoid assuming that OIDs are unique across tables,
because there is no way to enforce that.

There is some talk of eventually offering an 8-byte-OID compile-time
option, which would avoid this can of worms. However the pain level
would be high --- for example, did you know that there are OIDs in the
wire protocol? An 8-byte-OID server would not be able to talk to
4-byte-OID client libraries.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Paolo Sinigaglia 2001-03-01 16:33:21 R: Date types in where clause of PreparedStatement
Previous Message DaVinci 2001-03-01 15:46:04 JOIN of a table with many detail tables