Re: Commit ab596105b55 - BRIN minmax-multi indexes

Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com> writes:
> On Thu, Apr 15, 2021 at 7:49 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> As of right now, genbki.pl's OID counter reaches 12036, so it's
>> pretty clear that 12000 no longer works. (I have this figure in
>> my head because I noted it while working on [1].) 13000 might
>> well be an excessive jump though. Do you have a concrete problem
>> with it?

> In EDB Advance Server, it has their own set of system objects. Due
> to mentioned commit (where it changes the FirstBootstrapObjectId to 13000),
> now system objects exceeding the FirstNormalObjectId.

You might want to rethink where you're allocating those OIDs. Even if
we didn't move FirstBootstrapObjectId today, it's inevitably going to
creep up over time.

As I recall the discussions about this, we'd expected that add-on products
that need OIDs in the bootstrap range would take them from the 8K-10K
range, not above FirstBootstrapObjectId. Because of the possibility of
having lots of system locales creating lots of collations, the amount of
available OID space above FirstBootstrapObjectId is not as predictable as
you might wish. (I suspect eventually we're going to have to back off
the idea of creating every possible locale at bootstrap, but we haven't
addressed that yet.)

We are overlapping development use of the 8K-10K OID range with it being
available for add-ons post-release, which might make it hard to do testing
against HEAD. But you could renumber the not-yet-frozen objects' IDs out
of the way whenever you want to make a merge.

regards, tom lane