Re: [GENERAL] [ADMIN] How to set the global OID counter? COPY WITH OIDS does
True. Dirk Tom Lane wrote: =?ISO-8859-1?Q?Dirk_Lutzeb=E4ck?= <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Tel +49.30.5362.1635 Fax .1638 CTO AEC/communications GmbH, Berlin, Germany
Re: [GENERAL] [ADMIN] How to set the global OID counter? COPY WITH OIDS does
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 <[EMAIL PROTECTED]> 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
[GENERAL] 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] [ADMIN] dump/restore needed when switching from 32bit to 64bit
Thanks Tom, we now stay with 32bit to allow backward compatibilty with XEON which is needed as a fail-over system. The question is which gcc cflags are best used with XEON and Opteron to achieve fail-over compatibility. This is what we used for postgresql 8.0.3: XEON, RHEL 3.0 AS: CFLAGS = "-mcpu=pentium4 -march=pentium4" Opteron 875, RHEL 3.0 AS, gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42): CFLAGS = "-Acpu=x86_64 -Amachine=x86_64" Do we still need a dump/restore with this config? Regards, Dirk Tom Lane wrote: =?ISO-8859-1?Q?Dirk_Lutzeb=E4ck?= <[EMAIL PROTECTED]> writes: when have a 8.0.3 database running on a XEON machine. We want to replace it with an Opteron where postgresql is to be compiled with 64bit. Do we need a dump/restore or can we just start the db with the new compilation? I'd bet you need a dump/restore --- MAXALIGN is most likely different on the two platforms. If it isn't, then maybe you could get away with this, but it's definitely risky. regards, tom lane
[GENERAL] dump/restore needed when switching from 32bit to 64bit processor architecture?
Hi, when have a 8.0.3 database running on a XEON machine. We want to replace it with an Opteron where postgresql is to be compiled with 64bit. Do we need a dump/restore or can we just start the db with the new compilation? Regards, Dirk ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
