[PATCH v1] Fix pg_basebackup long-path test on Windows

Started by Harrison Booth9 days ago2 messageshackers
Jump to latest
#1Harrison Booth
harrisontbooth@gmail.com

PostgreSQL's pg_basebackup TAP test creates a junction from the short
system temporary directory to the build-tree temporary directory on
Windows. It then creates $superlongname through the build-tree side.

On my build, that target path was 253 characters. Perl's mkdir failed
at Windows' default 248-character directory path limit, but the result
was unchecked. The test then failed later with a misleading
CREATE TABLESPACE "directory does not exist" error.

The attached patch creates the directory through the short side of the
junction and checks the result of mkdir.

I tested current master 38afc3dcb25 with Meson 1.11.2 and MSVC 19.44 on
Windows 11 ARM64:

- Native ARM64: the unpatched isolated test failed; the patched test
passed all 149 subtests.
- x64 cross-build with needs_exe_wrapper=false: the unpatched test
failed; the patched test passed all 149 subtests.

The 2023 discussion below addressed a related pg_basebackup long-file
test. I did not find an existing proposal for this unchecked
long-directory creation.

/messages/by-id/666ac55b-3400-fb2c-2cea-0281bf36a53c@dunslane.net

Best,
Harrison

Attachments:

0001-Fix-pg_basebackup-long-path-test-on-Windows.patchapplication/octet-stream; name=0001-Fix-pg_basebackup-long-path-test-on-Windows.patchDownload+2-2
#2Daniel Gustafsson
daniel@yesql.se
In reply to: Harrison Booth (#1)
Re: [PATCH v1] Fix pg_basebackup long-path test on Windows

On 26 Jul 2026, at 02:02, Harrison Booth <harrisontbooth@gmail.com> wrote:

On my build, that target path was 253 characters. Perl's mkdir failed
at Windows' default 248-character directory path limit, but the result
was unchecked. The test then failed later with a misleading
CREATE TABLESPACE "directory does not exist" error.

-mkdir "$tempdir/$superlongname";
+mkdir "$real_sys_tempdir/$superlongname"
+  or BAIL_OUT "could not create $real_sys_tempdir/$superlongname";

Shouldn't this include $! to give a hint to the user what the error might be?

--
Daniel Gustafsson