Re: BUG #1814: Cancelling a CLUSTER changes the OID counter - Mailing list pgsql-bugs

From Ian Burrell
Subject Re: BUG #1814: Cancelling a CLUSTER changes the OID counter
Date
Msg-id d91f09cd05080910111e36be6@mail.gmail.com
Whole thread Raw
In response to Re: BUG #1814: Cancelling a CLUSTER changes the OID counter  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On 8/8/05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>=20
> Uh, does the same thing happen if you *don't* cancel it?
>=20

Yes.  In that case, it change the OID counter to the maximum OID in
the table if the OID counter was less than the maximum.  This is only
a problem when the OID counter has wrapped because until then there
are no OID higher than the counter.  I have verified it with a couple
of different tables different maximum OID; the counter went from 28
million, to 690 million, to 4286 million, to 4294 million.

> It looks to me like this could possibly happen due to CheckMaxObjectId()
> being applied to each OID found in the existing table.
>=20
> 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?
>=20

=46rom 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.

We are using PostgreSQL 7.4.6 but it looks like the same code is in 8.0.3.

 - Ian

pgsql-bugs by date:

Previous
From: "nguyen"
Date:
Subject: BUG #1817: column not exist
Next
From: Richard Huxton
Date:
Subject: Re: BUG #1817: column not exist