Ian Burrell <[EMAIL PROTECTED]> writes: > On 8/8/05, Tom Lane <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
