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