> 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...
If you want to make oids optional on user tables, we can vote on that.
However, OID's keep our system tables together. Though we don't need
them on every system table, it seems they should be on all system tables
just for completeness. Are we really losing a significant amount of
oids through system tables?
> > 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.)
Have we had a wraparound yet?
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026