On Sun, Jan 25, 2026 at 7:00 AM Alexander Lakhin <[email protected]> wrote: > 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)
Thanks for the report. I have pushed a commit to rename this test case to 011_incremental_backup_truncation_block to 011_ib_truncation, which I hope will be enough to fix this. I noticed when committing originally that this test case's name was a lot longer than anything else in the same directory, but I figured it didn't matter enough to bother changing it. Oops. I also wonder if there's some way we could change some of our pathname construction logic to mitigate this. Notice that in this pathname: 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 ...the full name of the test case appears twice, once as a subdirectory of pg_combinebackup, indicating which pg_combinebackup test is running, and then again as part of the name of the data directory. But why does the directory need to be named t_011_incremental_backup_truncation_block_primary_data instead of, you know, primary_data? I would sort of like to hope that in 2026, we wouldn't be subject to a 260-character pathname limit. But if we are, repeating the same strings multiple times in that pathname doesn't seem like the way to go. -- Robert Haas EDB: http://www.enterprisedb.com
