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

On Sun, Jan 25, 2026 at 7:00 AM Alexander Lakhin <exclusion(at)gmail(dot)com> 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