From: Chao Li <li.evan.chao@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Amul Sul <sulamul@gmail.com>
Cc: Oleg Tkachenko <oatkachenko@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: [BUG] [PATCH] pg_basebackup produces wrong incremental files after relation truncation in segmented tables
Date: Tue, 16 Dec 2025 16:05:56 +0800
Message-ID: <DA5AF966-A9D5-4C02-83B5-773AF47F5332@gmail.com> (raw)
In-Reply-To: <CA+TgmoZ7LQ40tLGpHw0U51CReH_8jv0sO0dALGRJp=FT+ZtGFQ@mail.gmail.com>
References: <00FEFC88-EA1D-4271-B38F-EB741733A84A@gmail.com>
<F687B661-E975-4383-8A94-F9130FE7ACC1@gmail.com>
<CAAJ_b94y98BWWgf0KMw-E_pqM_y8+RogqHtu5nK0kA1uBE3WWw@mail.gmail.com>
<CA+TgmoZ7LQ40tLGpHw0U51CReH_8jv0sO0dALGRJp=FT+ZtGFQ@mail.gmail.com>
> On Dec 16, 2025, at 00:35, Robert Haas <robertmhaas@gmail.com> wrote:
>
> [ sorry for not noticing this thread sooner; thanks to Andres for
> pointing me to it ]
>
> On Mon, Dec 15, 2025 at 9:01 AM Amul Sul <sulamul@gmail.com> wrote:
>> Thanks for the reproducer; I can see the reported issue, but I am not
>> quite sure the proposed fix is correct and might break other cases (I
>> haven't tried constructed that case yet) but there is a comment
>> detailing that case just before the point where you are planning to do
>> the changes:
>>
>> /*
>> * The truncation block length is the minimum length of the reconstructed
>> * file. Any block numbers below this threshold that are not present in
>> * the backup need to be fetched from the prior backup. At or above this
>> * threshold, blocks should only be included in the result if they are
>> * present in the backup. (This may require inserting zero blocks if the
>> * blocks included in the backup are non-consecutive.)
>> */
>>
>> IIUC, we might need the original assignment logic as it is. But we
>> need to ensure that truncation_block_length is not set to a value that
>> exceeds RELSEG_SIZE.
>
> I think you're right. By way of example, let's say that the current
> length of the file is 200 blocks, but the limit block is 100 blocks
> into the current segment. That means that the only blocks that we can
> get from any previous backup are blocks 0-99. Blocks 100-199 of the
> current segment are either mentioned in the WAL summaries we're using
> for this backup, or they're all zeroes. We can't set the
> truncation_block_length to a value greater than 100, or we'll go
> looking for the contents of any zero-filled blocks in previous
> backups, will will either fail or produce the wrong answer. But Oleg
> is correct that we also shouldn't set it to a value greater than
> RELSEG_SIZE. So my guess is that the correct fix might be something
> like the attached (untested, for discussion).
>
> --
> Robert Haas
> EDB: http://www.enterprisedb.com
> <v1-0001-Don-t-set-the-truncation_block_length-rather-than.patch>
The change looks good to me. Only nitpick is:
```
Subject: [PATCH v1] Don't set the truncation_block_length rather than
RELSEG_SIZE.
```
I guess you meant to say “larger (or greater) than” instead of “rather than”.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: li.evan.chao@gmail.com, robertmhaas@gmail.com, sulamul@gmail.com, oatkachenko@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: [BUG] [PATCH] pg_basebackup produces wrong incremental files after relation truncation in segmented tables
In-Reply-To: <DA5AF966-A9D5-4C02-83B5-773AF47F5332@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox