On Mon, Jul 18, 2022 at 02:57:40PM -0400, Robert Haas wrote: > So I tried implementing this but I didn't get it quite right the first > time. It's not enough to call smgrdounlinkall() instead of > RelationDropStorage(), because just as RelationDropStorage() does not > actually drop the storage but only schedules it to be dropped later, > so also smgrdounlinkall() does not in fact unlink all, but only some. > It leaves the first segment of the main relation fork around to guard > against the hazards discussed in the header comments for mdunlink(). > But those hazards don't really matter here either, because, again, any > failure will necessarily require that the entire new cluster be > destroyed, and also because there shouldn't be any concurrent activity > in the new cluster while pg_upgrade is running. So I adjusted > smgrdounlinkall() to actually remove everything when IsBinaryUpgrade = > true. And then it all seems to work: pg_upgrade of a cluster that has > had a rewrite of pg_largeobject works, and pg_upgrade of a cluster > that has not had such a rewrite works too. Wa-hoo.
Using the IsBinaryUpgrade flag makes sense to me. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson