Re: pg_combinebackup: incorrect size of VM fork after combine - Mailing list pgsql-hackers

From Robert Haas
Subject Re: pg_combinebackup: incorrect size of VM fork after combine
Date
Msg-id CA+TgmoYt0N4i5u0gpg_CdW7vL+0T-Ao7DVAqZjkCgOjN6sUm=A@mail.gmail.com
Whole thread Raw
In response to Re: pg_combinebackup: incorrect size of VM fork after combine  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
On Mon, Mar 9, 2026 at 11:42 AM Heikki Linnakangas <hlinnaka@iki.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



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Avoid resource leak (src/bin/pg_dump/pg_dumpall.c)
Next
From: Álvaro Herrera
Date:
Subject: Re: Avoid resource leak (src/bin/pg_dump/pg_dumpall.c)