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
-
Prevent restore of incremental backup from bloating VM fork.
- 076bc57fa46b 17.10 landed
- 9540c0e5dd40 18.4 landed
- ffc226ab64d4 19 (unreleased) landed