Re: pg15b2: large objects lost on upgrade
От | Robert Haas |
---|---|
Тема | Re: pg15b2: large objects lost on upgrade |
Дата | |
Msg-id | CA+TgmoaT_OMUjehQP8BvChV+5XJe3KUjiCLcad5NnvnQA5OkCA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg15b2: large objects lost on upgrade (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: pg15b2: large objects lost on upgrade
|
Список | pgsql-hackers |
On Thu, Jul 7, 2022 at 2:24 PM Bruce Momjian <bruce@momjian.us> wrote: > On Thu, Jul 7, 2022 at 01:38:44PM -0400, Robert Haas wrote: > > On Thu, Jul 7, 2022 at 1:10 PM Justin Pryzby <pryzby@telsasoft.com> wrote: > > > Maybe it's a good idea to check that the file is empty before unlinking... > > > > If we want to verify that there are no large objects in the cluster, > > we could do that in check_new_cluster_is_empty(). However, even if > > there aren't, the length of the file could still be more than 0, if > > there were some large objects previously and then they were removed. > > So it's not entirely obvious to me that we should refuse to remove a > > non-empty file. > > Uh, that initdb-created pg_largeobject file should not have any data in > it ever, as far as I know at that point in pg_upgrade. How would values > have gotten in there? Via pg_dump? I was thinking if the user had done it manually before running pg_upgrade. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: