Re: Why don't we have a small reserved OID range for patch revisions?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: John Naylor <john.naylor@2ndquadrant.com>
Cc: Peter Geoghegan <pg@bowt.ie>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-03-11T21:36:24Z
Lists: pgsql-hackers
Attachments
- v3-0001-Provide-OID-renumbering-script.patch (text/x-diff) patch v3-0001
John Naylor <john.naylor@2ndquadrant.com> writes: > Now it looks like: > perl renumber_oids.pl --first-mapped-oid 8000 --last-mapped-oid 8999 > --first-target-oid 2000 *.dat > To prevent a maintenance headache, I didn't copy any of the formatting > logic over. You'll also have to run reformat_dat_files.pl afterwards > to restore that. It seems to work, but I haven't tested thoroughly. I didn't like the use of Data::Dumper, because it made it quite impossible to check what the script had done by eyeball. After some thought I concluded that we could probably just apply the changes via search-and-replace, which is pretty ugly and low-tech but it leads to easily diffable results, whether or not the initial state is exactly what reformat_dat_files would produce. I also changed things so that the OID mapping is computed before we start changing any files, because as it stood the objects would get renumbered in a pretty random order; and I renamed one of the switches so they all have unique one-letter abbreviations. Experimenting with this, I realized that it couldn't renumber OIDs that are defined in .h files rather than .dat files, which is a serious deficiency, but given the search-and-replace implementation it's not too hard to fix up the .h files as well. So I did that, and removed the expectation that the target files would be listed on the command line; that seems more likely to be a foot-gun than to do anything useful. I've successfully done check-world after renumbering every OID above 4000 to somewhere else. I also tried renumbering everything below 4000, which unsurprisingly blew up because there are various catalog columns we haven't fixed to use symbolic OIDs. (The one that initdb immediately trips over is pg_database.dattablespace.) I'm not sure if it's worth the trouble to make that totally clean, but I suspect we ought to at least mop up text-search references to be symbolic. That's material for a separate patch though. This seems committable from my end --- any further comments? regards, tom lane
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