On 8/8/05, Tom Lane <[EMAIL PROTECTED]> 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 becau
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 h
"Ian Burrell" <[EMAIL PROTECTED]> writes:
> Cancelling a CLUSTER is causing the OID counter to jump forwards. In the
> test below, it goes from 108 million to 4286 million (close to 2^32).
> We recently wrapped the OID counter.
Uh, does the same thing happen if you *don't* cancel it?
It looks t
"Ian Burrell" <[EMAIL PROTECTED]> writes:
> Cancelling a CLUSTER is causing the OID counter to jump forwards. In the
> test below, it goes from 108 million to 4286 million (close to 2^32).
[ scratches head... ] Cannot duplicate this here. Does anyone else
see it?
regard
The following bug has been logged online:
Bug reference: 1814
Logged by: Ian Burrell
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.6
Operating system: RHEL 3 x86_64
Description:Cancelling a CLUSTER changes the OID counter
Details:
Cancelling a CLUSTER is
