Will LaShell <will@lashell.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
