Message-ID: <274e0a1a-d7d2-4bc8-8b56-dd09f285715e@gmail.com>
Date: Sun, 25 Jan 2026 14:00:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [BUG] [PATCH] pg_basebackup produces wrong incremental files
 after relation truncation in segmented tables
To: Robert Haas <robertmhaas@gmail.com>, Andrew Dunstan <andrew@dunslane.net>
Cc: Amul Sul <sulamul@gmail.com>, pgsql-hackers@lists.postgresql.org,
 Oleg Tkachenko <oatkachenko@gmail.com>,
 Stanislav Bashkyrtsev <stanislav.bashkyrtsev@elsci.io>
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>
 <22474984-C4CD-4300-A84E-C1CA58F61CDA@gmail.com>
 <CA+TgmobbxO26OcYcruA=qjSfKeQRzEF_n3_Ljs9ts1MTzCSWxg@mail.gmail.com>
 <A4159D9E-C980-4782-9B91-4B41410AE374@gmail.com>
 <CAAJ_b95v6Kbby_YkBbvAgdujEM7uD7YCTCa62upSZjexsZ8qgw@mail.gmail.com>
 <CA+Tgmoa6aSg-zNDs6F9FtFrjrCozt0_32yQkom9BZsLi-REWAA@mail.gmail.com>
 <08EA8874-0114-4E5C-A794-EB40C971EE7C@gmail.com>
 <CA+Tgmob2j58xsksWMPHfyXBMq4go4qKWyMJWeE6QUugLp6hVXQ@mail.gmail.com>
 <6897DAF7-B699-41BF-A6FB-B818FCFFD585@gmail.com>
 <CA+TgmobgoOHjjHzK1WXnBSR7p2o7VxC1S6cfdEY2cFSKaekfxA@mail.gmail.com>
 <1E2326C0-185A-4D91-867C-18BF94D186DD@gmail.com>
 <CA+TgmoZ_zLO7ROr1KQZ1znqLg3+uL16wc2S01r6UtcwUiHm+_Q@mail.gmail.com>
Content-Language: en-US
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: 
 <CA+TgmoZ_zLO7ROr1KQZ1znqLg3+uL16wc2S01r6UtcwUiHm+_Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/274e0a1a-d7d2-4bc8-8b56-dd09f285715e%40gmail.com>
Precedence: bulk

Hello Robert,

19.01.2026 19:42, Robert Haas wrote:
> On Fri, Jan 16, 2026 at 7:10 AM Oleg Tkachenko <oatkachenko@gmail.com> wrote:
>> As you suggested, I've updated the test so that it produces small files consistently across platforms.
>> On one specific platform (with segment size = 6 blocks), it still exercises the relevant code path.
>> And I've also applied the style changes you mentioned.
> Thanks. I have committed the fix and back-patched to v17. I made some
> style changes to your test, especially rewriting comments, but the
> substance of it is unchanged.

As Windows animal fairywren shows at [1],  the test
011_incremental_backup_truncation_block, added by ecd275718, hit Windows
limitation to the path length:
126/281 postgresql:pg_combinebackup / pg_combinebackup/011_incremental_backup_truncation_block ERROR            96.71s   
(exit status 255 or signal 127 SIGinvalid)

log/011_incremental_backup_truncation_block_primary.log contains:
...
2026-01-20 02:11:14.760 UTC [7480:2] [unknown] LOG:  connection authenticated: user="pgrunner" method=trust 
(C:/tools/xmsys64/home/pgrunner/bf/root/REL_18_STABLE/pgsql.build/testrun/pg_combinebackup/011_incremental_backup_truncation_block/data/t_011_incremental_backup_truncation_block_primary_data/pgdata/pg_hba.conf:117)
...
2026-01-20 02:11:23.506 UTC [1252:3] LOG:  checkpoint starting: immediate force wait
2026-01-20 02:11:23.580 UTC [1252:4] LOG:  checkpoint complete: wrote 5 buffers (3.9%), wrote 1 SLRU buffers; 0 WAL 
file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.001 s, total=0.074 s; sync files=0, longest=0.000 s, 
average=0.000 s; distance=32768 kB, estimate=32768 kB; lsn=0/4000080, redo lsn=0/4000028
2026-01-20 02:11:23.974 UTC [8968:2] ERROR:  could not rename file "pg_wal/summaries/temp.summary" to 
"pg_wal/summaries/00000001000000000100002800000000010CAA50.summary": No such file or directory
         1 file(s) copied.
2026-01-20 02:11:33.645 UTC [7968:14] 011_incremental_backup_truncation_block.pl WARNING:  still waiting for WAL 
summarization through 0/4000028 after 10 seconds
2026-01-20 02:11:33.645 UTC [7968:15] 011_incremental_backup_truncation_block.pl DETAIL:  Summarization has reached 
0/1000000 on disk and 0/10CAA50 in memory.

That is, the target filename for the rename operation is:
C:/tools/xmsys64/home/pgrunner/bf/root/REL_18_STABLE/pgsql.build/testrun/pg_combinebackup/011_incremental_backup_truncation_block/data/t_011_incremental_backup_truncation_block_primary_data/pgdata/pg_wal/summaries/00000001000000000100002800000000010CAA50.summary

I can reproduce this locally with the source tree located at
/c/src/postgresql12345678901234567890123456789012345678901.
Not reproduced with HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled set to 1.

Note that the test passes at the master branch ([2]) because "master" is
shorter than "REL_18_STABLE" by 7 chars.

See also [3].

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren&dt=2026-01-20%2001%3A26%3A02
[2] https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=fairywren&dt=2026-01-24%2010%3A03%3A10&stg=misc-check
[3] https://www.postgresql.org/message-id/666ac55b-3400-fb2c-2cea-0281bf36a53c%40dunslane.net

Best regards,
Alexander