Re: Re: AW: Re: OID wraparound: summary and proposal - Mailing list pgsql-hackers

From Doug McNaught
Subject Re: Re: AW: Re: OID wraparound: summary and proposal
Date
Msg-id m3g0avzvcx.fsf@belphigor.mcnaught.org
Whole thread Raw
In response to AW: Re: OID wraparound: summary and proposal  ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>)
List pgsql-hackers
mlw <markw@mohawksoft.com> writes:

> Somehow I guess I created a misunderstanding. I don't really care about
> ROWID. I care that OID is a 32 bit number. The notion that each table could
> have its own "OID" similar to a ROWID could be an intermediate solution. I
> have flip-flopped a couple times about whether or not the OID being able to
> be eliminated from some tables is a good idea. Some code depends on the
> OID.

See below...

> The way I see it there are 4 options for the OID:

> (2) Allow the ability to have tables without OIDs. This is a source of
> debate.

If we do this, and default OIDs to "on", honestly, where's the
problem?  If the DBA does nothing, things work as before (with
potential OID wraparound issues).  If you want to avoid/minimize the
issues, turn off OIDs on your large tables, and write/fix your code to
cope.

> (3) Allow tables to have their own notion of an OID. This is harder to do,
> and also a source of debate.
> (4) Make OIDs 64 or 128 bit. (there are platform issues.)

(5) [this was suggested earlier] Create separate spaces for "system"
and "user" OIDs.  This requires a similar mechanism to (3), but may be 
somewhat easier.

-Doug
-- 
Free Dmitry Sklyarov! 
http://www.freesklyarov.org/ 

We will return to our regularly scheduled signature shortly.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: [PATCHES] Select parser at runtime
Next
From: Doug McNaught
Date:
Subject: Re: Perl,Postmaster and CPU question??