Re: BUG #1814: Cancelling a CLUSTER changes the OID counter

Ian Burrell <ianburrell(at)gmail(dot)com> writes:
> On 8/8/05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> It looks to me like this could possibly happen due to CheckMaxObjectId()
>> being applied to each OID found in the existing table.
>>
>> CheckMaxObjectId was always a kluge, and I'm not sure that it still has
>> any redeeming social value at all. Can anyone think of a good reason
>> to keep it?

> From looking in the code, I am pretty sure CheckMaxObjectId is the
> culprit. It sets the nextOID to the oid in the row if the
> assigned_oid is greater than the nextOID.

Yeah. This is closely related to my recent speculations about putting
in a more direct defense against duplicate OIDs:

http://archives.postgresql.org/pgsql-hackers/2005-08/msg00074.php

I think if we did that, particularly in the general any-unique-OID-index
form suggested here

http://archives.postgresql.org/pgsql-hackers/2005-08/msg00247.php

then we could feel justified in simply discarding CheckMaxObjectId.
We would then have a mechanism that guaranteed OID uniqueness on a
per-table basis, but not at all on a cluster-wide basis, which is
the mindset that CheckMaxObjectId comes from. In environments where
databases live long enough to have OID wraparound, CheckMaxObjectId
is worse than useless --- it creates uniqueness problems rather than
avoiding them, because it tends to force the OID counter to hover near
the high end of the range.

Comments?

regards, tom lane