vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org |
| |||
| 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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly |
| |||
| 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend |
| |||
| 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> 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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match |
| ||||
| 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 |