Обсуждение: How to set the global OID counter? COPY WITH OIDS does not set global OID counter?
How to set the global OID counter? COPY WITH OIDS does not set global OID counter?
От
Dirk Lutzebäck
Дата:
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
Re: [ADMIN] How to set the global OID counter? COPY WITH OIDS does not set global OID counter?
От
Alvaro Herrera
Дата:
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:
How does 8.1 prevent to allocate duplicate OIDs?
Regards,
Dirk
Tom Lane wrote:
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
=?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:
Dirk
Tom Lane wrote:
Dirk Lutzebäck <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.
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, 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