Tom Lane писал(а) 2026-07-31 22:03:
Vladlen Popolitov <[email protected]> writes:
Tom Lane писал(а) 2026-07-31 20:07:
Yeah, that sounds like the solution with the smallest blast radius.
I'll go make it so in a bit. Thanks for the report!
I have already created and tested a new patch based on this idea.
Oh, I'd already pushed an equivalent fix in win32link.c before
seeing this message.
It fixes the link() error handling. The patch also fixes dolink()
on Linux and FreeBSD, since these platforms are affected as well.
I hope this can be fixed in upstream tzcode.
Eggert already committed something, as per the [email protected] thread.
I don't want to take a local patch that doesn't match his, and I'm
not really in a big hurry to worry about this on Linux/*BSD anyway.
I think there are few people installing zoneinfo trees on
non-hard-link filesystems on those platforms, else he'd have gotten
pushback sooner. (I didn't research their git history, but I'm
thinking this error behavior has probably been in tzcode for awhile.)
There are even fewer people doing so with Postgres' copy of zic,
because I imagine just about everyone on those platforms uses
--with-system-tzdata instead of a private, often out-of-date zoneinfo
tree. So I'm content to let this go for non-Windows until the next
time we sync our copy of tzcode.
Tom,
Thank you for the quick fix. I'm glad this is resolved.
This issue came up unexpectedly while I was working with other
patches on Windows. I was using an exFAT drive for the build,
and the build stopped with the link() error. The previous
version of zic handled this correctly because it had slightly
different logic for fallback.
By the way, I am also working on another patch related to link
on Windows (pgsymlink() which uses junction points). In
the PostgreSQL code, there is an incorrect constant used
for buffer length (to short). This can cause failures not
only on servers but also during builds and tests, because
Meson tends to create very long directory names. As a result,
one of the build tests starts failing.
There is a discussion about this issue in the hackers list,
and another participant has confirmed the failure:
https://www.postgresql.org/message-id/flat/ac3f262fdc3613acfb88176972938fd1%40postgrespro.ru
Best regards,
Vladlen
