How to set the global OID counter? COPY WITH OIDS does not set global OID counter?
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@commandprompt.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 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:
Show quoted text
Alvaro Herrera <alvherre@commandprompt.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
Show quoted text
On 6/9/06, Dirk Lutzebäck <lutzeb@aeccom.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@commandprompt.com> <alvherre@commandprompt.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@aeccom.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@aeccom.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@aeccom.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@aeccom.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@aeccom.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@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461