I was able to reproduce the issue. Also, the issue does not occur with code before to preserve relfilenode commit. I tested your patch and it fixes the problem. I am currently analyzing a few things related to the issue. I will come back once my analysis is completed.
On Sat, Jul 2, 2022 at 9:19 PM Justin Pryzby <pry...@telsasoft.com> wrote: > On Sat, Jul 02, 2022 at 08:34:04AM -0400, Robert Haas wrote: > > On Fri, Jul 1, 2022 at 7:14 PM Justin Pryzby <pry...@telsasoft.com> > wrote: > > > I noticed this during beta1, but dismissed the issue when it wasn't > easily > > > reproducible. Now, I saw the same problem while upgrading from beta1 > to beta2, > > > so couldn't dismiss it. It turns out that LOs are lost if VACUUM FULL > was run. > > > > Yikes. That's really bad, and I have no idea what might be causing it, > > either. I'll plan to investigate this on Tuesday unless someone gets > > to it before then. > > I suppose it's like Bruce said, here. > > https://www.postgresql.org/message-id/20210601140949.GC22012%40momjian.us > > |One tricky case is pg_largeobject, which is copied from the old to new > |cluster since it has user data. To preserve that relfilenode, you would > |need to have pg_upgrade perform cluster surgery in each database to > |renumber its relfilenode to match since it is created by initdb. I > |can't think of a case where pg_upgrade already does something like that. > > Rather than setting the filenode of the next object as for user tables, > pg-upgrade needs to UPDATE the relfilenode. > > This patch "works for me" but feel free to improve on it. >
