Re: Replacing pg_depend PIN entries with a fixed range check

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Subject: Re: Replacing pg_depend PIN entries with a fixed range check
Date: 2021-05-27 22:53:50
Message-ID: 1938032.1622156030@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> The first hunk of the patch seems to back away from the idea that the
>> cutoff is 13000, but the second half of the patch says 13000 still
>> matters. Not sure I understand what's going on there exactly.

> Not sure exactly what you're looking at, but IIRC there is a place
> where the patch is cleaning up after ab596105b's failure to adjust
> bki.sgml to match its change of FirstBootstrapObjectId from 12000
> to 13000. I hadn't bothered to fix that separately, but I guess
> we should do so, else v14 is going to ship with incorrect docs.

I take that back: I had committed that doc fix, in 1f9b0e693, so
I'm still unsure what was confusing you. (But a4390abec just
reverted it, anyway.)

Attached is a rebase over a4390abec. The decision in that commit
to not expect global uniqueness of OIDs above 10K frees us to use
a much simpler solution than before: we can just go ahead and start
the backend's OID counter at 10000, and not worry about conflicts,
because the OID generation logic can deal with any conflicts just
fine as long as you're okay with only having per-catalog uniqueness.
So this gets rid of the set_next_oid mechanism that I'd invented in
v2, and yet there's still no notable risk of running out of OIDs in
the 10K-12K range.

While testing this, I discovered something that I either never knew
or had forgotten: the bootstrap backend is itself assigning some
OIDs, specifically OIDs for the composite types associated with most
of the system catalogs (plus their array types). I find this scary,
because it is happening before we've built the catalog indexes, so
it's impossible to ensure uniqueness. (Of course, when we do build
the indexes, we'd notice any conflicts; but that's not a solution.)
I think it accidentally works because we don't ask genbki.pl to
assign any pg_type OIDs, but that seems fragile. Seems like maybe
we should fix genbki.pl to assign those OIDs, and then change
GetNewOidWithIndex to error out in bootstrap mode. However that's a
pre-existing issue, so I don't feel that this patch needs to be
the one to fix it.

regards, tom lane

Attachment Content-Type Size
remove-pg_depend-PIN-entries-3.patch text/x-diff 53.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2021-05-27 23:25:01 Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involving system columns
Previous Message Peter Geoghegan 2021-05-27 22:52:06 Re: Move pg_attribute.attcompression to earlier in struct for reduced size?