Re: pg_combinebackup: incorrect size of VM fork after combine

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Amul Sul <sulamul@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Oleg Tkachenko <oatkachenko@gmail.com>
Date: 2026-03-09T16:48:38Z
Lists: 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



Commits

  1. Prevent restore of incremental backup from bloating VM fork.