| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Amul Sul <sulamul(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Oleg Tkachenko <oatkachenko(at)gmail(dot)com> |
| Subject: | Re: pg_combinebackup: incorrect size of VM fork after combine |
| Date: | 2026-03-09 16:48:38 |
| Message-ID: | CA+TgmoYt0N4i5u0gpg_CdW7vL+0T-Ao7DVAqZjkCgOjN6sUm=A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Mar 9, 2026 at 11:42 AM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> For 'master', I wonder if we should change the 'xl_smgr_create' record
> format to directly include the new sizes of all of the truncated forks.
> It's always felt error-prone to me that the redo function recomputes
> those. It's a little more complicated for the redo function, as it needs
> to also clear out part of the last remaining page, but that information
> could also be included in the WAL record directly.
Possibly -- or at least improve the comments. I was very confused
about how this works for a long time. One advantage of the current
system is that it keeps the WAL record small, but it's unlikely that
the additional bytes in an infrequently-used record type would matter
to many people. An advantage of listing the sizes explicitly is that
it would accommodate hypothetical relation forks where the other-fork
size can't be trivially derived from the main-fork size, but I'm
unconvinced we're ever going to add such a relation fork. I don't
really know what the right thing to do is.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Álvaro Herrera | 2026-03-09 16:51:48 | Re: Avoid resource leak (src/bin/pg_dump/pg_dumpall.c) |
| Previous Message | Andrew Dunstan | 2026-03-09 16:41:03 | Re: Avoid resource leak (src/bin/pg_dump/pg_dumpall.c) |