Re: 4 billion + oids

My guess is most of the applications on postgress wouldn't
totally rely on oids, though they may implicitly use them
if they use standard sql create table statements. My
concern is that during the wrap arounds this could create
unintended problems in table, index creations or
elsewhere. Probably its worthwhile to enumerate the list
of potential problems (eg what we now know table creation,
index creation), their error messages (so applicatons can
handle them cleanly) and possibly their workarounds. This
list could then be very useful as part of the discussion
on oids in the documentation.

Thanks...
Amin

On Mon, 24 Mar 2003 01:46:36 -0500
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>"Andrew Bartley" <abartley(at)evolvosystems(dot)com> writes:
>> We have found this to be a major problem. It seems once
>>the OIDs wrap; we =
>> constantly get errors due to "Cannot insert a duplicate
>>key into unique ind=
>> ex pg_class_oid_index". There are about 3,000 entries
>>in pg_class at this =
>> stage.
>
>Once the OID counter wraps, there's certainly some risk
>of OID
>collisions. However, if you have only 3000 entries in
>pg_class it's
>hard to see why the odds would be worse than
>3000/4billion or less than
>one failure in 1 million tries. I think there is
>something you have not
>told us.
>
>The nearby suggestions to minimize the rate of OID
>consumption seem
>rather beside the point from here ... what I'd wonder
>about is why you
>need as many as three thousand tables. Reducing that
>footprint should
>reduce the odds of OID collision.
>
> regards, tom lane
>
>
>---------------------------(end of
>broadcast)---------------------------
>TIP 6: Have you searched our list archives?
>
>http://archives.postgresql.org