Release notes on "reserved OIDs"
I happened across this bit in the v12 release notes:
<listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
2018-12-13 [09568ec3d] Create a separate oid range for oids assigned by genbki.
-->
<para>
Reserve a range of OIDs (9000-9999) to be used for external
extensions (Andres Freund)
</para>
</listitem>
This seems more or less completely misleading. There is no project policy
saying that we won't ever use those OIDs. Moreover, in view of a6417078c
(which you don't seem to have documented at all), what we really ought to
be saying is that new patches ought to be using OIDs in 8000-9999 with the
expectation that those will get renumbered later.
That does have the effect that shipped releases probably won't use those
OIDs anytime in the near future ... but there's a lot of daylight between
that and giving a promise that we won't ever use them period. In
particular, I could see somebody citing this text as a reason to complain
that "my extension isn't working with v15devel because commit NNNN used
some random OIDs above 9K".
regards, tom lane
On 2019-Aug-30, Tom Lane wrote:
<listitem>
<!--
Author: Andres Freund <andres@anarazel.de>
2018-12-13 [09568ec3d] Create a separate oid range for oids assigned by genbki.
--><para>
Reserve a range of OIDs (9000-9999) to be used for external
extensions (Andres Freund)
</para>
</listitem>This seems more or less completely misleading.
Hmm. I wonder if this item really belongs in the release notes at all.
My view is that this was interim policy, not necessarily a permanent
thing; and it's oriented strictly towards PG developers rather than end
users or even fork-developers.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Hmm. I wonder if this item really belongs in the release notes at all.
My view is that this was interim policy, not necessarily a permanent
thing; and it's oriented strictly towards PG developers rather than end
users or even fork-developers.
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.
regards, tom lane
On Fri, Aug 30, 2019 at 12:35:09PM -0400, Tom Lane wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Hmm. I wonder if this item really belongs in the release notes at all.
My view is that this was interim policy, not necessarily a permanent
thing; and it's oriented strictly towards PG developers rather than end
users or even fork-developers.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.
OK, sure. I was just basing the release notes on this commit text:
Add a note suggesting that oids in forks should be assigned in the
9000-9999 range.
I was looking to see information that was relevant for the release
notes. Please update as desired.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Hi,
On 2019-08-30 12:35:09 -0400, Tom Lane wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Hmm. I wonder if this item really belongs in the release notes at all.
My view is that this was interim policy, not necessarily a permanent
thing; and it's oriented strictly towards PG developers rather than end
users or even fork-developers.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?
Greetings,
Andres Freund
Hi,
On 2019-08-30 22:44:53 -0400, Bruce Momjian wrote:
On Fri, Aug 30, 2019 at 12:35:09PM -0400, Tom Lane wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Hmm. I wonder if this item really belongs in the release notes at all.
My view is that this was interim policy, not necessarily a permanent
thing; and it's oriented strictly towards PG developers rather than end
users or even fork-developers.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.OK, sure. I was just basing the release notes on this commit text:
Add a note suggesting that oids in forks should be assigned in the
9000-9999 range.
But how do you get from forks in that sentence from the commit message
(or the source, which says " with 9000-9999 tentatively reserved for
forks"), to the range being for "external extensions"? Those are very
different things imo?
Greetings,
Andres Freund
Andres Freund <andres@anarazel.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
Hi,
On 2019-09-04 09:41:43 -0400, Tom Lane wrote:
Andres Freund <andres@anarazel.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.
Given the timeline 09568ec3d really couldn't forsee a6417078c...
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.
Should we just update the comment to reference that then?
Greetings,
Andres Freund
Andres Freund <andres@anarazel.de> writes:
On 2019-09-04 09:41:43 -0400, Tom Lane wrote:
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.
Should we just update the comment to reference that then?
WFM.
I'm planning to make a pass over the release notes soon, and will
update this one when I get to it.
regards, tom lane
On 9/4/19 11:11 AM, Tom Lane wrote:
I'm planning to make a pass over the release notes soon, and will
update this one when I get to it.
-list (figured it was off topic but apropos) -- Bruce had reached out to
me offlist that he is about to be traveling and may need to have someone
else look over a couple of patches I posted on the docs thread[1]/messages/by-id/82e96a75-f124-6dc0-ac4e-7d039c8db796@postgresql.org[2]/messages/by-id/c2490b7a-dfd3-2d78-babf-5537c483fcc7@postgresql.org,
one containing the "big items for 12" -- so putting it on your radar in
case it was not on your scan.
He also mentioned he had already had a fix for the patch I had posted in
"icu-ordering.patch"[3]/messages/by-id/5450d3bb-2544-464b-b416-2f08877cebaf@postgresql.org but I did not see anything get committed.
Thanks,
Jonathan
[1]: /messages/by-id/82e96a75-f124-6dc0-ac4e-7d039c8db796@postgresql.org
/messages/by-id/82e96a75-f124-6dc0-ac4e-7d039c8db796@postgresql.org
[2]: /messages/by-id/c2490b7a-dfd3-2d78-babf-5537c483fcc7@postgresql.org
/messages/by-id/c2490b7a-dfd3-2d78-babf-5537c483fcc7@postgresql.org
[3]: /messages/by-id/5450d3bb-2544-464b-b416-2f08877cebaf@postgresql.org
/messages/by-id/5450d3bb-2544-464b-b416-2f08877cebaf@postgresql.org
On Wed, Sep 4, 2019 at 02:43:15AM -0700, Andres Freund wrote:
Hi,
On 2019-08-30 22:44:53 -0400, Bruce Momjian wrote:
On Fri, Aug 30, 2019 at 12:35:09PM -0400, Tom Lane wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Hmm. I wonder if this item really belongs in the release notes at all.
My view is that this was interim policy, not necessarily a permanent
thing; and it's oriented strictly towards PG developers rather than end
users or even fork-developers.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.OK, sure. I was just basing the release notes on this commit text:
Add a note suggesting that oids in forks should be assigned in the
9000-9999 range.But how do you get from forks in that sentence from the commit message
(or the source, which says " with 9000-9999 tentatively reserved for
forks"), to the range being for "external extensions"? Those are very
different things imo?
I conflated forks and extensions in my head because they both are
external efforts that integrate with Postgres.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +