On Wed, Feb 27, 2019 at 10:41 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > In short, this situation may look fine from the perspective of a committer > with a relatively short timeline to commit, but it's pretty darn awful for > everybody else. The only way to avoid a ~ 50% failure rate is to choose > OIDs above 6K, and once everybody starts doing it like that, things are > going to get very unpleasant very quickly.
The root problem here from the perspective of a non-committer is not that they might have to renumber OIDs a few times over the year or two it takes to get their patch merged, but rather that it takes a year or two to get their patch merged. That's not to say that I have no sympathy with people in that situation or don't want to make their lives easier, but I'm not really convinced that burdening committers with additional manual steps is the right way to get patches merged faster. This seems like a big piece of new mechanism being invented to solve an occasional annoyance. Your statistics are not convincing at all: you're arguing that this is a big problem because 2-3% of pending patches current have an issue here, and some others have in the past, but that's a really small percentage, and the time spent doing OID renumbering must be a tiny percentage of the total time anyone spends hacking on PostgreSQL. I think that the problem here is have a very limited range of OIDs (10k) which can be used for this purpose, and the number of OIDs that are used in that space is now a significant fraction of the total (>4.5k), and the problem is further complicated by the desire to keep the OIDs assigned near the low end of the available numbering space and/or near to other OIDs used for similar purposes. The sheer fact that the address space is nearly half-used means that conflicts are likely even if people choose OIDs at random, and when people choose OIDs non-randomly -- lowest, round numbers, near to other OIDs -- the chances of conflicts just go up. We could fix that problem by caring less about keeping all the numbers gapless and increasing the size of the reserved space to say 100k, but 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? Make a way that people can add an entry to pg_proc.dat or whatever without fixing an OID, and let the build scripts generate one. As many patches as happen during a release cycle will add new such entries and they'll just all get some OID or other. Then, at the end of the release cycle, we'll run a script that finds all of those catalog entries and rewrites the .dat files, adding a permanent OID assignment to each one, so that those OIDs will then be fixed for all future releases (unless we drop the entries or explicitly change something). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
