OID wraparound (was Re: pg_depend)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: OID wraparound (was Re: pg_depend)
Date: 2001-07-18 17:52:45
Message-ID: 6335.995478765@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephan Szabo 2001-07-18 18:06:56 Re: ERROR: SELECT DISTINCT ON with postgresql v 7.1.2
Previous Message Mark R DeLong 2001-07-18 17:43:56 pg_dump(all) fails with "failed sanity chec, type with oid ..."