OID wraparound (was Re: pg_depend) - Mailing list pgsql-hackers

From Tom Lane
Subject OID wraparound (was Re: pg_depend)
Date
Msg-id 6335.995478765@sss.pgh.pa.us
Whole thread Raw
Responses Re: OID wraparound (was Re: pg_depend)  (Lamar Owen <lamar.owen@wgcr.org>)
Re: OID wraparound (was Re: pg_depend)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: OID wraparound (was Re: pg_depend)  (Tatsuo Ishii <t-ishii@sra.co.jp>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Yikes, I am not sure we are ready to make oids optional.

We've discussed it enough, it's time to do it.  I have an ulterior plan
here: I want 7.2 not to have any limitations that prevent it from being
used in a true 24x7, up-forever scenario.  VACUUM lockouts are fixed
now, or nearly.  The other stumbling blocks for continuous runs are OID
wraparound and XID wraparound.  We've got unique indexes on OIDs for all
system catalogs that need them (we were short a couple as of 7.1, btw),
but OID wrap is still likely to lead to unwanted "duplicate key"
failures.  So we still need a way to reduce the system's appetite for
OIDs.  In a configuration where OIDs are used only where *necessary*,
it'd be a long time till wrap.  I also intend to do something about XID
wrap next month...

> Do we return unused oids back to the pool on backend exit yet?

Since WAL, and that was never a fundamental answer anyway.

> Will we have cheap 64-bit oids by the time oid wraparound becomes an
> issue?

No, we won't, because OID wrap is an issue already for any long-uptime
installation.  (64-bit XIDs are not a real practical answer either,
btw.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Idea: recycle WAL segments, don't delete/recreate 'em
Next
From: Tom Lane
Date:
Subject: Re: pg_depend