Re: Oid registry - Mailing list pgsql-hackers

Andrew Dunstan <andrew@dunslane.net> writes:
> On 09/24/2012 09:24 PM, Tom Lane wrote:
>> Another point to think about is that it's a few years too late to
>> guarantee that any particular OID above 16384 is unused; we can't
>> do that now without possibly breaking pg_upgrade-ability of existing
>> databases.  While we could hand out some subrange of the OIDs below
>> that, there's not exactly a huge amount of space available.

> we seem to have a fair bit of leeway between to top numbered Oid as 
> reported by unused_oids (4332) and 16384.

It's not nearly that simple.  Per transam.h:
*        OIDs 1-9999 are reserved for manual assignment (see the files*        in src/include/catalog/).**        OIDS
10000-16383are reserved for assignment during initdb*        using the OID generator.  (We start the generator at
10000.)**       OIDs beginning at 16384 are assigned from the OID generator*        during normal multiuser operation.
(Weforce the generator up to*        16384 as soon as we are in normal operation.)
 

pg_database.datlastsysoid is 12907 as of HEAD, so we're using about 2900
OIDs that are assigned during initdb.  We should expect continued growth
in that number.  For comparison, it was 10791 in 8.1, which was the first
version following this assignment scheme --- so the number of
auto-assigned OIDs has more than tripled in the last seven years.
And there's not room for another tripling.  So I think it's entirely
likely that we'll have to reduce FirstBootstrapObjectId to a smaller
number in the foreseeable future, or else increase FirstNormalObjectId
which would be a pg_upgrade breaking move.  Meanwhile, we do continue to
eat manually-assigned OIDs at a nontrivial pace as well.

So, yeah, we could reserve a couple hundred OIDs for a scheme like this
and (probably) not regret it later.  But a couple thousand would scare
me ... and I'm not exactly convinced that a couple hundred is enough,
if there's any demand out there at all.

I suggest we could consider handing out reserved OIDs one or two at a
time using the current manual assignment process, *without* any notion
of a reserved block of OIDs.  That is, when Joe Developer needs a couple
of OIDs for joes_whizzy_datatype, he comes to us and we say "sure, you
can have 4333 and 4334", which we then memorialize in a text file in
include/catalog/.  This doesn't preclude doing something differently
later of course, but it avoids setting aside OID address space that is
likely to be underutilized and fairly desperately needed at some future
time.

As you might guess from this, I'm not enamored of the "reserve some
private OID space" part at all.  There's not been any demand for that
that I've noticed.  In pretty much any development context, you could
use OIDs up around 4 billion for such purposes and not have any problem
at all --- it's only trying to *guarantee* they're not used anywhere out
in the field that is problematic.
        regards, tom lane