Re: pg15b2: large objects lost on upgrade
От | Julien Rouhaud |
---|---|
Тема | Re: pg15b2: large objects lost on upgrade |
Дата | |
Msg-id | 20220702155208.6tlmapfrqidpzumv@jrouhaud обсуждение исходный текст |
Ответ на | Re: pg15b2: large objects lost on upgrade (Robert Haas <robertmhaas@gmail.com>) |
Список | 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 по дате отправления: