Re: Commit ab596105b55 - BRIN minmax-multi indexes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Commit ab596105b55 - BRIN minmax-multi indexes
Date
Msg-id 3781047.1618499431@sss.pgh.pa.us
Whole thread Raw
In response to Re: Commit ab596105b55 - BRIN minmax-multi indexes  (Rushabh Lathia <rushabh.lathia@gmail.com>)
List pgsql-hackers
Rushabh Lathia <rushabh.lathia@gmail.com> writes:
> On Thu, Apr 15, 2021 at 7:49 PM Tom Lane <tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: Jeevan Ladhe
Date:
Subject: Re: Remove redundant variable from transformCreateStmt
Next
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: Schema variables - new implementation for Postgres 15