Thread: an OID >= 8000 in master
Hello.
I happened to find that the commit 71dcd74 added the function
"network_sortsupport" with OID = 8190. Is it right? Otherwise we
should we move it to, say, 4035.
(I understand that OID [8000, 9999] are development-use.)
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From d838f3ec847c6b5093e7a4df6192056e953db998 Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Date: Thu, 21 Nov 2019 10:32:33 +0900
Subject: [PATCH] Change OID of a function.
Commit 71dcd74386 used an OID in the range 8000-9999, which are for
development-use. Change it to lower value.
---
src/include/catalog/pg_proc.dat | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/include/catalog/pg_proc.dat b/src/include/catalog/pg_proc.dat
index 58ea5b982b..c1abf4accf 100644
--- a/src/include/catalog/pg_proc.dat
+++ b/src/include/catalog/pg_proc.dat
@@ -3960,7 +3960,7 @@
{ oid => '3551',
proname => 'network_overlap', prorettype => 'bool',
proargtypes => 'inet inet', prosrc => 'network_overlap' },
-{ oid => '8190', descr => 'sort support',
+{ oid => '4035', descr => 'sort support',
proname => 'network_sortsupport', prorettype => 'void',
proargtypes => 'internal', prosrc => 'network_sortsupport' },
--
2.23.0
On Thu, Nov 21, 2019 at 10:44:30AM +0900, Kyotaro Horiguchi wrote: > I happened to find that the commit 71dcd74 added the function > "network_sortsupport" with OID = 8190. Is it right? Otherwise we > should we move it to, say, 4035. > > (I understand that OID [8000, 9999] are development-use.) Yep, agreed. This looks like an oversight. Peter? -- Michael
Attachment
On Wed, Nov 20, 2019 at 5:44 PM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > I happened to find that the commit 71dcd74 added the function > "network_sortsupport" with OID = 8190. Is it right? Otherwise we > should we move it to, say, 4035. > > (I understand that OID [8000, 9999] are development-use.) I committed this patch using an OID in that range intentionally. Commit a6417078 established a new project policy around OID assignment. It will be renumbered at the end of the release cycle. The unused_oids script will now actively suggest that patch authors use a particular random OID from this range, so this will probably be very common soon. -- Peter Geoghegan
On Wed, Nov 20, 2019 at 6:07 PM Michael Paquier <michael@paquier.xyz> wrote: > Yep, agreed. This looks like an oversight. Peter? It's not an oversight. See the commit message of a6417078, and the additions that were made to the RELEASE_CHANGES file. -- Peter Geoghegan
At Wed, 20 Nov 2019 18:10:09 -0800, Peter Geoghegan <pg@bowt.ie> wrote in > On Wed, Nov 20, 2019 at 6:07 PM Michael Paquier <michael@paquier.xyz> wrote: > > Yep, agreed. This looks like an oversight. Peter? > > It's not an oversight. See the commit message of a6417078, and the > additions that were made to the RELEASE_CHANGES file. Mmm... a6417078: > * After feature freeze in each development cycle, run renumber_oids.pl > to move all such OIDs down to lower numbers, thus freeing the high OID > range for the next development cycle. I thought that commits don't use the development OIDs and thought that we won't have conflict perfectly. So, still any ongoing patch can stamp on another when it is committed by certain probability (even if it's rather low)). And consecutive high-OID "hole"s are going to be shortened and decrease throgh a year. By the way even if we work this way, developers tend to pick up low range OIDs since it is printed at the beginning of the output. I think we should hide the whole list of unused oids defaultly and just suggest random one. $ ./unused_oids Suggested random unused OID: 8057 (133 consecutive OID(s) available starting here) If you need more OIDs, try run this script again or unused_oids -v (for example) to show the complete list of unused OIDs. $ ./unused_oids Suggested random unused OID: 8182 (8 consecutive OID(s) available starting here) If you need more OIDs, try run this script again or unused_oids -v (for example) to show the complete list of unused OIDs. $ ./unused_oids -v 4 - 9 210 270 - 273 ... 8191 8193 - 9999 Patches should use a more-or-less consecutive range of OIDs. Best practice is to start with a random choice in the range 8000-9999. Suggested random unused OID: 8342 (1658 consecutive OID(s) available starting here) Thoughts? regards. -- Kyotaro Horiguchi NTT Open Source Software Center
On Wed, Nov 20, 2019 at 8:33 PM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > So, still any ongoing patch can stamp on another when it is committed > by certain probability (even if it's rather low)). And consecutive > high-OID "hole"s are going to be shortened and decrease throgh a year. Right. > By the way even if we work this way, developers tend to pick up low > range OIDs since it is printed at the beginning of the output. I think > we should hide the whole list of unused oids defaultly and just > suggest random one. It is still within the discretion of committers to use the non-reserved/development OID ranges directly. For example, a committer may prefer to use an OID that is close to the OIDs already used for a set of related objects, if the related objects are already in a stable release. (I'm not sure that it's really worth doing that, but that's what the policy is.) -- Peter Geoghegan
Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> At Wed, 20 Nov 2019 18:10:09 -0800, Peter Geoghegan <pg@bowt.ie> wrote in
>> On Wed, Nov 20, 2019 at 6:07 PM Michael Paquier <michael@paquier.xyz> wrote:
>>> Yep, agreed. This looks like an oversight. Peter?
>> It's not an oversight. See the commit message of a6417078, and the
>> additions that were made to the RELEASE_CHANGES file.
Yes, the idea is that picking random OIDs in the 8000-9999 range is
less likely to cause conflicts between patches than our old habits.
> I thought that commits don't use the development OIDs and thought that
> we won't have conflict perfectly.
I do not think there is any easy solution that guarantees that.
We could imagine having some sort of pre-registration mechanism,
maybe, but it seems like more trouble than benefit.
> By the way even if we work this way, developers tend to pick up low
> range OIDs since it is printed at the beginning of the output. I think
> we should hide the whole list of unused oids defaultly and just
> suggest random one.
-1, that pretty much destroys the point of the unused_oids script.
regards, tom lane
At Wed, 20 Nov 2019 20:44:18 -0800, Peter Geoghegan <pg@bowt.ie> wrote in > It is still within the discretion of committers to use the > non-reserved/development OID ranges directly. For example, a committer That happens at feature freeze. Understood. At Wed, 20 Nov 2019 23:45:21 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote in > > I thought that commits don't use the development OIDs and thought that > > we won't have conflict perfectly. > > I do not think there is any easy solution that guarantees that. > We could imagine having some sort of pre-registration mechanism, > maybe, but it seems like more trouble than benefit. If we don't intend what Peter pointed (arrangement of low-OIDs at feature freeze), it can be done by moving OIDs to lower values at commit. (I don't mean commiters should do that, it may be bothersome.) > > By the way even if we work this way, developers tend to pick up low > > range OIDs since it is printed at the beginning of the output. I think > > we should hide the whole list of unused oids defaultly and just > > suggest random one. > > -1, that pretty much destroys the point of the unused_oids script. Is the "point" is what the name suggests? The tool is, for developers, a means of finding OIDs *usable for their project*. It doesn't seem appropriate to show OIDs that developers are supposed to refrain from using. In my proposal the tool still shows all unused OIDs as the name suggests when some option specified. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> At Wed, 20 Nov 2019 23:45:21 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote in
>> I do not think there is any easy solution that guarantees that.
>> We could imagine having some sort of pre-registration mechanism,
>> maybe, but it seems like more trouble than benefit.
> If we don't intend what Peter pointed (arrangement of low-OIDs at
> feature freeze), it can be done by moving OIDs to lower values at
> commit. (I don't mean commiters should do that, it may be bothersome.)
Yes, that's exactly the point: when we discussed this new policy,
it was agreed that making committers deal with the issue in each
commit was an unreasonable burden. Aside from just being more
work, there's the risk that two committers working on different
patches concurrently would choose to map the development OIDs to
the same "final" OIDs. It seems better to deal with the problem
once at feature freeze.
Anyway, we've only had this policy in place for a few months.
I'm not eager to redesign it until we've had more experience.
>>> By the way even if we work this way, developers tend to pick up low
>>> range OIDs since it is printed at the beginning of the output. I think
>>> we should hide the whole list of unused oids defaultly and just
>>> suggest random one.
>> -1, that pretty much destroys the point of the unused_oids script.
> Is the "point" is what the name suggests? The tool is, for developers,
> a means of finding OIDs *usable for their project*. It doesn't seem
> appropriate to show OIDs that developers are supposed to refrain from
> using. In my proposal the tool still shows all unused OIDs as the name
> suggests when some option specified.
The existing output seems perfectly clear to me. What you propose
just adds complication and reduces usefulness.
regards, tom lane
At Thu, 21 Nov 2019 10:35:25 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote in > > If we don't intend what Peter pointed (arrangement of low-OIDs at > > feature freeze), it can be done by moving OIDs to lower values at > > commit. (I don't mean commiters should do that, it may be bothersome.) > > Yes, that's exactly the point: when we discussed this new policy, > it was agreed that making committers deal with the issue in each > commit was an unreasonable burden. Aside from just being more > work, there's the risk that two committers working on different > patches concurrently would choose to map the development OIDs to > the same "final" OIDs. It seems better to deal with the problem > once at feature freeze. > > Anyway, we've only had this policy in place for a few months. > I'm not eager to redesign it until we've had more experience. Thanks for the explantion. I understood and agreed. > >>> By the way even if we work this way, developers tend to pick up low > >>> range OIDs since it is printed at the beginning of the output. I think > >>> we should hide the whole list of unused oids defaultly and just > >>> suggest random one. > > >> -1, that pretty much destroys the point of the unused_oids script. > > > Is the "point" is what the name suggests? The tool is, for developers, > > a means of finding OIDs *usable for their project*. It doesn't seem > > appropriate to show OIDs that developers are supposed to refrain from > > using. In my proposal the tool still shows all unused OIDs as the name > > suggests when some option specified. > > The existing output seems perfectly clear to me. What you propose > just adds complication and reduces usefulness. For clarity, it's perfect also to me. I don't insist on the change since no supporters come up. regards. -- Kyotaro Horiguchi NTT Open Source Software Center