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

From Julien Rouhaud
Subject Re: pg15b2: large objects lost on upgrade
Date
Msg-id 20220702155208.6tlmapfrqidpzumv@jrouhaud
Whole thread Raw
In response to Re: pg15b2: large objects lost on upgrade  (Robert Haas <robertmhaas@gmail.com>)
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.

As far as I can see the data is still there, it's just that the new cluster
keeps its default relfilenode instead of preserving the old cluster's value:

regression=# table pg_largeobject;
 loid | pageno | data
------+--------+------
(0 rows)

regression=# select oid, relfilenode from pg_class where relname = 'pg_largeobject';
 oid  | relfilenode
------+-------------
 2613 |        2613
(1 row)

-- using the value from the old cluster
regression=# update pg_class set relfilenode = 39909 where oid = 2613;
UPDATE 1

regression=# table pg_largeobject;
 loid  | pageno |
-------+--------+-----------------
 33211 |      0 | \x0a4920776[...]
 34356 |      0 | \xdeadbeef
(2 rows)



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: pg15b2: large objects lost on upgrade
Next
From: Tom Lane
Date:
Subject: Re: PSA: Autoconf has risen from the dead