[ connecting up two threads here ]
I wrote:
> Hence, what this patch does is to establish a manually-managed cutoff
> point akin to FirstBootstrapObjectId, and make initdb push the OID
> counter up to that once it's made the small number of pinned objects
> it's responsible for. With the value I used here, a couple hundred
> OIDs are wasted, but there seems to be a reasonable amount of headroom
> still beyond that. On my build, the OID counter at the end of initdb
> is 15485 (with a reasonable number of glibc and ICU locales loaded).
> So we still have about 900 free OIDs there; and there are 500 or so
> free just below FirstBootstrapObjectId, too. So this approach does
> hasten the day when we're going to run out of free OIDs below 16384,
> but not by all that much.
In view of the discussion at [1], there's more pressure on the OID supply
above 10K than I'd realized. While I don't have any good ideas about
eliminating the problem altogether, I did have a thought that would remove
the extra buffer zone created by my first-draft patch in this thread.
Namely, let's have genbki.pl write out its final OID assignment counter
value in a command in the postgres.bki file, say "set_next_oid 12036".
This would cause the bootstrap backend to set the server's OID counter to
that value. Then the initial part of initdb's post-bootstrap processing
could assign pinned OIDs working forward from there, with no gap. We'd
still need a gap before FirstBootstrapObjectId (which we might as well
rename to FirstUnpinnedObjectId), but we don't need two gaps, and so this
patch wouldn't make things any worse than they are today.
I'm not planning to put more effort into this patch right now, but
I'll revise it along these lines once v15 development opens.
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/CAGPqQf3JYTrTB1E1fu_zOGj%2BrG_kwTfa3UcUYPfNZL9o1bcYNw%40mail.gmail.com
