Re: pg_combinebackup: incorrect size of VM fork after combine

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

In response to

Browse pgsql-hackers by date

  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)