Re: Release notes on "reserved OIDs"

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-docs(at)lists(dot)postgresql(dot)org
Subject: Re: Release notes on "reserved OIDs"
Date: 2019-09-04 13:41:43
Message-ID: 22548.1567604503@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2019-08-30 12:35:09 -0400, Tom Lane wrote:
>> I think it's the sort of thing that we sometimes cover in the
>> "source code" changes of the release notes. But yeah, 09568ec3d's
>> idea was pretty much fully superseded by a6417078c, so if we're
>> going to document anything it should be the latter not the former.

> Hm - not sure I see how a6417078c supersedes 09568ec3d, on the rationale
> that we'd discussed in the thread, which the commit message sums up as:
> Add a note suggesting that oids in forks should be assigned in the
> 9000-9999 range.
> As forks != extensions, the release note entry seems misleading, and
> a6417078c doesn't seem relevant?

If we were trying to honor that rule, we'd be asking patches to use
temporary OIDs that don't fall into the 9K range. Otherwise, a fork
that thinks it has private OIDs up there is going to have intermittent
trouble tracking HEAD.

As things stand after a6417078c, the safest place for a fork to put
private OIDs is actually from 7999 down; patches shouldn't touch that
range, and it'll be a long time till we hit it working up.

regards, tom lane

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Andres Freund 2019-09-04 15:00:05 Re: Release notes on "reserved OIDs"
Previous Message PG Doc comments form 2019-09-04 13:12:35 uniqueness and null could benefit from a hint for dba