Re: automatically assigning catalog toast oids - Mailing list pgsql-hackers

Andres Freund <andres@anarazel.de> writes:
> On 2018-12-09 17:14:42 -0500, Tom Lane wrote:
>> Well, that's just a different very-easily-broken assumption.  There are
>> a lot of things that make auto-assigned OIDs unstable, and I do not think
>> that we want to guarantee that they'll hold still across a release series.

> Why wouldn't they be for genbki (rather than initdb) assigned oids?  I
> don't think it's reasonable to add new functions or such post release
> that would have move oid assignments for other objects?

As you've got this set up, we couldn't change *anything* for fear of
it moving auto-assignments; there's no isolation between catalogs.

Another thing I seriously dislike is that this allows people to omit OIDs
from .dat entries in catalogs where we traditionally hand-assign OIDs.
That's not a good idea because it would mean those entries don't have
stable OIDs, whereas the whole point of hand assignment is to ensure
all built-in objects of a particular type have stable OIDs.  Now, you
could argue about the usefulness of that policy for any given catalog;
but if we decide that catalog X doesn't need stable OIDs then that should
be an intentional policy change, not something that can happen because
one lazy hacker didn't follow the policy.

(This is, btw, another reason why I don't much like allowing toast
tables to not have stable OIDs; it confuses what the policy is for
pg_class.)

>> In fact, I think it's about guaranteed to blow
>> up in the face of anybody who inserts manually-assigned OIDs above
>> around 9000.

> I'm not sure I really see a pressing problem with that. I think it'd not
> be insane to treat this as a "well, don't do that then".

I can name more than one company that will be pretty damn unhappy when
we break their local patches that make use of 9K-range OIDs.  For better
or worse, the policy for the last 20 years has been that OIDs up to 9999
are available for hand assignment.  What you've just done is to break
that for OIDs above some boundary that's not even very well defined
(though it seems to be somewhere around 8500 as of HEAD).

>> What we probably need to do is restructure the FirstBootstrapObjectId
>> business so that there are separate, well-defined ranges for genbki.pl
>> and initdb to use.

> I'm fine with adding a distinct range, the earlier version of the patch
> had that. I'd asked for comments if anybody felt a need to keep that,
> nobody replied...  I alternatively proposed that we could just start at
> FirstNormalObjectId for those and update the server's oid start value to
> the maximum genbki assigned oid.  Do you have preferences around that?

Yeah, I thought about the latter as well.  But it adds complexity to the
bootstrap process and makes it harder to tell what assigned a particular
OID, so I'd rather go with the former, at least until the OID situation
gets too tight to allow for daylight between the ranges.

It looks to me like as of HEAD, genbki.pl is auto-assigning about 1470
OIDs.  Meanwhile, on my RHEL6 machine, initdb is auto-assigning about
1740 OIDs (what a coincidence); of those, 872 are collation entries
that are absorbed from the system environment.  So the second number is
likely to vary a lot from platform to platform.  (I don't have ICU
enabled; I wonder how many that typically adds.)

I'd be inclined to allow say 2000 OIDs for genbki.pl, with 4384 therefore
available for initdb.  We could expect to have to raise the boundary
from time to time, but not very often.

            regards, tom lane