"Josh Berkus" <josh@agliodbs.com> writes:
>> No, it uses all oids, and can create duplicates.
> Does this mean that Tom's "Wraparound Ragnarok" is the
> accurate scenario?
There's nothing particularly magic about OIDs. If your programs
don't use OIDs to identify rows, then you don't care whether there
are duplicate OIDs or not. If they do, you can still protect yourself
by creating a unique index on OID for the tables where you need OID to
be unique. You might get unexpected insert failures due to OID conflict
after a wraparound, but the odds are in your favor (ie, retrying will
probably succeed).
Postgres itself assumes that OIDs are unique in some of the system
tables, but I believe we have unique indexes in place for the tables
where it matters. So, again, transient insert failures seem like the
worst likely consequence ... annoying, but not exactly Ragnarok.
Transaction ID wraparound is a less pleasant scenario :-(. You'd
probably be well advised to dump/reload your DB when you start to
approach 4G transactions through it. I think we might be able to
fix this so that things are OK as long as you vacuum more frequently
than once per wraparound, but no one's looked at the problem yet.
As Bruce pointed out, we have yet to hear from anyone who's run a
Postgres DB long enough to run into either sort of wraparound, so
these issues don't seem all that pressing...
regards, tom lane