Re: [ADMIN] How to set the global OID counter? COPY WITH OIDS does

Hi,

how can one set the global OID counter in 8.1.X? We think it would work
in 8.0.X using the COPY WITH OIDS command but this does not work in
8.1.X anymore.

We have the problem that we made a dump using 'pg_dump -o' in 8.0.X,
created a new database in 8.1.X and read back in but the global OID
counter stayed at 40.000 so OIDs will be allocated again!

Thanks for help,

Dirk

Dirk Lutzebäck wrote:
> Hi,
>
> how can one set the global OID counter in 8.1.X? We think it would work
> in 8.0.X using the COPY WITH OIDS command but this does not work in
> 8.1.X anymore.

pg_resetxlog -o
(Postmaster stopped of course)

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Dirk Lutzebck wrote:
>> how can one set the global OID counter in 8.1.X? We think it would work
>> in 8.0.X using the COPY WITH OIDS command but this does not work in
>> 8.1.X anymore.

> pg_resetxlog -o
> (Postmaster stopped of course)

Possibly more to the point: why do you think you need to mess with the
counter? 8.1 is smart enough not to assign conflicting OIDs to large
objects.

regards, tom lane

This is not a large object. We are seeing rows with duplicate oids
because the OID counter is not changed after the dump (exported with
--oids) is being loaded.
How does 8.1 prevent to allocate duplicate OIDs?

Regards,

Dirk

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>
>> Dirk Lutzebäck wrote:
>>
>>> how can one set the global OID counter in 8.1.X? We think it would work
>>> in 8.0.X using the COPY WITH OIDS command but this does not work in
>>> 8.1.X anymore.
>>>
>
>
>> pg_resetxlog -o
>> (Postmaster stopped of course)
>>
>
> Possibly more to the point: why do you think you need to mess with the
> counter? 8.1 is smart enough not to assign conflicting OIDs to large
> objects.
>
> regards, tom lane
>

this is an important enough question that no one who asks it has to provide
an answer as to why they're doing it.

i can imagine many situations where this would be useful, not the least of
which is reliability testing. and ESPECIALLY since OID's apparently roll
over at 2^32. what happens if you have more than 4 billion rows in the
database?

that's totally unrelated to setting the oid counter though. come on. give
it up! how do you do it?

colin

On 6/9/06, Dirk Lutzebäck <lutzeb(at)aeccom(dot)com> wrote:
>
> This is not a large object. We are seeing rows with duplicate oids
> because the OID counter is not changed after the dump (exported with --oids)
> is being loaded.
> How does 8.1 prevent to allocate duplicate OIDs?
>
> Regards,
>
> Dirk
>
> Tom Lane wrote:
>
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> <alvherre(at)commandprompt(dot)com> writes:
>
> Dirk Lutzebäck wrote:
>
> how can one set the global OID counter in 8.1.X? We think it would work
> in 8.0.X using the COPY WITH OIDS command but this does not work in
> 8.1.X anymore.
>
> pg_resetxlog -o
> (Postmaster stopped of course)
>
> Possibly more to the point: why do you think you need to mess with the
> counter? 8.1 is smart enough not to assign conflicting OIDs to large
> objects.
>
> regards, tom lane
>
>
>

=?ISO-8859-1?Q?Dirk_Lutzeb=E4ck?= <lutzeb(at)aeccom(dot)com> writes:
> This is not a large object. We are seeing rows with duplicate oids
> because the OID counter is not changed after the dump (exported with
> --oids) is being loaded.
> How does 8.1 prevent to allocate duplicate OIDs?

If there's a unique index on the OID column then 8.1 will not allocate
duplicate OIDs. If there's not such a unique index, you had no
guarantee of no-duplicates before 8.1 either.

regards, tom lane

True.

Dirk

Tom Lane wrote:
> =?ISO-8859-1?Q?Dirk_Lutzeb=E4ck?= <lutzeb(at)aeccom(dot)com> writes:
>
>> This is not a large object. We are seeing rows with duplicate oids
>> because the OID counter is not changed after the dump (exported with
>> --oids) is being loaded.
>> How does 8.1 prevent to allocate duplicate OIDs?
>>
>
> If there's a unique index on the OID column then 8.1 will not allocate
> duplicate OIDs. If there's not such a unique index, you had no
> guarantee of no-duplicates before 8.1 either.
>
> regards, tom lane
>

--
/This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you are not the intended recipient, you should not copy
it, re-transmit it, use it or disclose its contents, but should return
it to the sender immediately and delete your copy from your system.
Thank you for your cooperation./

*Dirk Lutzebäck* <lutzeb(at)aeccom(dot)com> Tel +49.30.5362.1635 Fax .1638
CTO AEC/communications GmbH <http://www.aeccom.com>, Berlin, Germany

In the future, please don't send the same email to a bunch of pgsql
lists; one is almost always sufficient. (In this case, -admin OR
-general woulud have been best).

On Fri, Jun 09, 2006 at 05:27:47PM +0200, Dirk Lutzeb?ck wrote:
> True.
>
> Dirk
>
> Tom Lane wrote:
> >=?ISO-8859-1?Q?Dirk_Lutzeb=E4ck?= <lutzeb(at)aeccom(dot)com> writes:
> >
> >>This is not a large object. We are seeing rows with duplicate oids
> >>because the OID counter is not changed after the dump (exported with
> >>--oids) is being loaded.
> >>How does 8.1 prevent to allocate duplicate OIDs?
> >>
> >
> >If there's a unique index on the OID column then 8.1 will not allocate
> >duplicate OIDs. If there's not such a unique index, you had no
> >guarantee of no-duplicates before 8.1 either.
> >
> > regards, tom lane
> >
>
> --
> /This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they are
> addressed. If you are not the intended recipient, you should not copy
> it, re-transmit it, use it or disclose its contents, but should return
> it to the sender immediately and delete your copy from your system.
> Thank you for your cooperation./
>
> *Dirk Lutzeb?ck* <lutzeb(at)aeccom(dot)com> Tel +49.30.5362.1635 Fax .1638
> CTO AEC/communications GmbH <http://www.aeccom.com>, Berlin, Germany
>

--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461