Re: Why don't we have a small reserved OID range for patch revisions?
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-02-28T23:57:12Z
Lists: pgsql-hackers
On Thu, Feb 28, 2019 at 3:40 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: > >>> just as a thought, what if we stopped assigning manual OIDs for new > >>> catalog entries altogether, except for once at the end of each release > >>> cycle? > > Actually ... that leads to an idea that wouldn't add any per-commit > overhead, or really much change at all to existing processes. Given > the existence of a reliable OID-renumbering tool, we could: > In this scheme, OID collisions are a problem for in-progress patches > only if two patches are unlucky enough to choose the same random > high OIDs during the same devel cycle. That's unlikely, or at least > a good bit less likely than collisions are today. That sounds like a reasonable compromise. Perhaps the unused_oids script could give specific guidance on using a randomly determined small range of contiguous OIDs that fall within the current range for that devel cycle. That would prevent collisions caused by the natural human tendency to prefer a round number. Having contiguous OIDs for the same patch seems worth preserving. -- Peter Geoghegan
Commits
-
Remove remaining hard-wired OID references in the initial catalog data.
- 3aa0395d4ed3 12.0 landed
-
Create a script that can renumber manually-assigned OIDs.
- a6417078c414 12.0 landed
-
Minor improvements for reformat_dat_file.pl.
- 27aaf6eff49a 12.0 landed