| From: | Ian Burrell <ianburrell(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #1814: Cancelling a CLUSTER changes the OID counter |
| Date: | 2005-08-09 17:11:41 |
| Message-ID: | d91f09cd05080910111e36be6@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 8/8/05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Uh, does the same thing happen if you *don't* cancel it?
>
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.
>
> 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.
We are using PostgreSQL 7.4.6 but it looks like the same code is in 8.0.3.
- Ian
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-08-09 17:26:08 | Re: BUG #1814: Cancelling a CLUSTER changes the OID counter |
| Previous Message | Tom Lane | 2005-08-09 03:31:37 | Re: BUG #1814: Cancelling a CLUSTER changes the OID counter |