Horton

Re: [BUG] [PATCH] pg_basebackup produces wrong incremental files after relation truncation in segmented tables

amul sul <sulamul@gmail.com>

View thread
From: Amul Sul <sulamul@gmail.com>
To: Oleg Tkachenko <oatkachenko@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@lists.postgresql.org, Stanislav Bashkyrtsev <stanislav.bashkyrtsev@elsci.io>
Date: 2025-12-18T06:05:11Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Don't set the truncation block length greater than RELSEG_SIZE.

Attachments

On Wed, Dec 17, 2025 at 3:25 AM Oleg Tkachenko <oatkachenko@gmail.com> wrote:
>
> Hello, Robert
>
> I’ve created a small test that reproduces the issue. With the proposed fix applied, the test passes, and the reconstruction behaves as expected.
>
> I’m attaching the test for review. Please let me know if this looks OK or if you would like it changed.
>

Test looks good to me, but I have three suggestions as follow:

1. To minimize repetition in insert: use fillfactor 10, which is the
minimal we can set for a table, so that we can minimize tuples per
page. Use a longer string and lower count in repeat(), which I believe
helps the test become a bit faster.

2. I think we could add this test to the existing pg_combinebackup's
test file instead of creating a new file with a single-test. See the
attached version; it’s a bit smaller than your original patch, but
since I haven't copied all of your comments yet, I’ve marked it as
WIP.

3. Kindly combine the code fix and tests together into a single patch.

Regards,
Amul