On Sat, Jul 2, 2022 at 11:49 AM Justin Pryzby <pry...@telsasoft.com> wrote: > I suppose it's like Bruce said, here. > > https://www.postgresql.org/message-id/20210601140949.GC22012%40momjian.us
Well, I feel dumb. I remember reading that email back when Bruce sent it, but it seems that it slipped out of my head between then and when I committed. I think your patch is fine, except that I think maybe we should adjust this dump comment: -- For binary upgrade, set pg_largeobject relfrozenxid, relminmxid and relfilenode Perhaps: -- For binary upgrade, preserve values for pg_largeobject and its index Listing the exact properties preserved seems less important to me than mentioning that the second UPDATE statement is for its index -- because if you look at the SQL that's generated, you can see what's being preserved, but you don't automatically know why there are two UPDATE statements or what the rows with those OIDs are. I had a moment of panic this morning where I thought maybe the whole patch needed to be reverted. I was worried that we might need to preserve the OID of every system table and index. Otherwise, what happens if the OID counter in the old cluster wraps around and some user-created object gets an OID that the system tables are using in the new cluster? However, I think this can't happen, because when the OID counter wraps around, it wraps around to 16384, and the relfilenode values for newly created system tables and indexes are all less than 16384. So I believe we only need to fix pg_largeobject and its index, and I think your patch does that. Anyone else see it differently? -- Robert Haas EDB: http://www.enterprisedb.com
