Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible
| От | Nathan Bossart |
|---|---|
| Тема | Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible |
| Дата | |
| Msg-id | aYzuAz_ITUpd9ZvH@nathan обсуждение исходный текст |
| Ответ на | Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible (Nathan Bossart <nathandbossart@gmail.com>) |
| Ответы |
Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible
Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible |
| Список | pgsql-hackers |
On Sun, Feb 08, 2026 at 04:00:40PM -0600, Nathan Bossart wrote: > On Sun, Feb 08, 2026 at 04:26:41PM -0500, Andres Freund wrote: >> On 2026-02-05 15:29:55 -0600, Nathan Bossart wrote: >>> + * commands. We can only do this for upgrades from v12 and newer; in >>> + * older versions, pg_largeobject_metadata was created WITH OIDS, so the >>> + * OID column is hidden and won't be dumped. >>> */ >> >> It's not really related to this change, but what is that WITH OIDS bit about? >> Sure, they aren't shown by default, but all it takes to change that is to >> explicitly add the output column? I'm not saying we have to do that, I just >> don't understand the reasoning as written here. > > IIRC the issue is that getTableAttrs() won't pick up the OID column on > older versions. It might be easy to fix that by adjusting its query for > binary upgrades from <v12. That could be worth doing, if for no other > reason than to simplify some of the pg_dump code. I'll make a note of it. This was a little more painful than I expected, but this seems to be what is required to allow COPY-ing pg_largeobject_metadata during binary upgrades from < v12. -- nathan
Вложения
В списке pgsql-hackers по дате отправления: