Bug and memory leaks with access to file links with long names (Windows, MSVS)
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t50826psql -h localhost -U postgresBuilt from patchset v1 (message #1), August 23, 2026 at 03:33 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t50826_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t50826_1 && git checkout t50826_1Patchset v1 (message #1) is on t50826_1
Hi!
PostgreSQL build under Windows with MS Visual Studio has functions to
work with
links (unlike msys2 that has own functions). If a database has link
pointing
to location longer 130 chars, function pgreadlink fails to recognise
this
link and cancels query.
The reason of the error - small buffer for link name - MAX_PATH
symbols, though this
buffer must have the place for at least 2 MAX_PATH : substitution and
print names
of the link.
How to reproduce:
If build directory has length ~100 chars or longer,
pg_rewind/004_pg_xlog_symlink
test will fail (Windows, MSVS build)
Steps to reproduce:
call "C:\Program Files\Microsoft Visual
Studio\2022\Community\VC\Auxiliary\Build\vcvarsall.bat" x64
SET LC_MESSAGES=C
SET
BUILDDIR=c:\postgresql-builds\length_30\length_40\length_50\length_60\length_70\length_80\length_90\length100\
meson setup %BUILDDIR% --prefix=c:\postgresql-builds\install
c:
cd %BUILDDIR%
meson compile -C %BUILDDIR%
meson install -C %BUILDDIR%
meson test -C %BUILDDIR%
Memory leak:
In case of error the function in the code branch reporting the error
does not return
Windows file handle and Windows heap allocation for error message text.
Solution:
Proposed patch fixes link information buffer size changing it to the
documented value
MAXIMUM_REPARSE_DATA_BUFFER_SIZE,
and fixes memory leaks - the message buffer copied to a buffer on stack
with maximal message size 64Kb.
--
Best regards,
Vladlen Popolitov.
Vladlen,
I reproduced the pg_rewind/004_pg_xlog_symlink failure on current master
38afc3dcb25 using Meson 1.11.2 and MSVC 19.44 on Windows 11 ARM64.
- Native ARM64: the unpatched test failed with "could not get junction
for pg_wal: More data is available." Your v1 patch applied cleanly,
rebuilt successfully, and passed all 10 subtests.
- x64 cross-build with needs_exe_wrapper=false: the unpatched test
failed with the same junction error. Your v1 patch rebuilt
successfully and passed all 10 subtests.
This confirms the issue and the v1 fix on current master in both Windows
ARM64 configurations.
Best,
Harrison
Harrison Booth писал(а) 2026-07-26 03:04:
Vladlen,
I reproduced the pg_rewind/004_pg_xlog_symlink failure on current
master
38afc3dcb25 using Meson 1.11.2 and MSVC 19.44 on Windows 11 ARM64.- Native ARM64: the unpatched test failed with "could not get junction
for pg_wal: More data is available." Your v1 patch applied cleanly,
rebuilt successfully, and passed all 10 subtests.
- x64 cross-build with needs_exe_wrapper=false: the unpatched test
failed with the same junction error. Your v1 patch rebuilt
successfully and passed all 10 subtests.This confirms the issue and the v1 fix on current master in both
Windows
ARM64 configurations.
Yes. I worked with other bug under Windows, and this failed test
waqs very annoying. After investigation I did that patch and reported
it.
Probably it was better to send it to commitfest and try to commit.
Best,
Harrison
--
Best regards,
Vladlen Popolitov.