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