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

Hello Robert,

19.01.2026 19:42, Robert Haas wrote:
> On Fri, Jan 16, 2026 at 7:10 AM Oleg Tkachenko <oatkachenko(at)gmail(dot)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