Re: pg15b2: large objects lost on upgrade - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: pg15b2: large objects lost on upgrade
Date
Msg-id 20220702154917.GM13040@telsasoft.com
Whole thread Raw
In response to Re: pg15b2: large objects lost on upgrade  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pg15b2: large objects lost on upgrade
Re: pg15b2: large objects lost on upgrade
List pgsql-hackers
On Sat, Jul 02, 2022 at 08:34:04AM -0400, Robert Haas wrote:
> On Fri, Jul 1, 2022 at 7:14 PM Justin Pryzby <pryzby@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.

Attachment

pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Support logical replication of DDLs
Next
From: Julien Rouhaud
Date:
Subject: Re: pg15b2: large objects lost on upgrade