Skip site navigation (1) Skip section navigation (2)

Re: Using oid with RServ w/ Postgresql 7.2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Will LaShell <will(at)lashell(dot)net>
Cc: "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Using oid with RServ w/ Postgresql 7.2
Date: 2002-10-21 17:26:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
Will LaShell <will(at)lashell(dot)net> writes:
> On Thu, 2002-10-17 at 18:55, Tom Lane wrote:
>> This is risky for a long-lived database.  Things will work fine until
>> the OID counter wraps around (ie, more than 4 billion rows inserted
>> into your database).  After that you have a risk of OID collisions.
>> You can prevent the worst problems by installing a unique index on OID
>> on each replicated table; but then you may occasionally get unexpected
>> "duplicate key" errors.

> Just out of curiousity, when OID wraparound happens, won't there be
> bigger problems? 

No, occasional "duplicate key" errors are about what you'd have to deal
with, assuming you have unique indexes on OID on every table where OID
matters to you.

You might also have some problems with pg_dump dumping things in a funny
order, because it relies on OID comparisons to try to guess the creation
order of objects.  We have plans to fix that in the future (maybe for
7.4), but for now it'd mean you'd need to manually edit the dump file
to fix the dump order.  (Or use the custom dump format and make use of
pg_restore's ability to restore things in a specified order.)

			regards, tom lane

In response to

pgsql-admin by date

Next:From: Rusty WrightDate: 2002-10-21 18:22:31
Subject: Re: newbie qs; examining databases and tables
Previous:From: Will LaShellDate: 2002-10-21 17:07:24
Subject: Re: Using oid with RServ w/ Postgresql 7.2

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group