From: | r(dot)zharkov(at)postgrespro(dot)ru |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Checking pgwin32_is_junction() errors |
Date: | 2022-08-08 08:23:30 |
Message-ID: | 4590c37927d7b8ee84f9855d83229018@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2022-08-06 08:02, Thomas Munro wrote:
>
> Pushed.
>
> Hmm, this stuff could *really* use a little test framework that's run
> by check-world, that exercises these various replacement operations.
> But I also suspect that problems in this area are likely to be due to
> concurrency. It's hard to make a simple test that simulates the case
> where a file is unlinked between system calls within stat() and hits
> the STATUS_DELETE_PENDING case. That check is code I cargo-culted in
> this patch. So much of the stuff we've had in the tree relating to
> that area has been wrong in the past...
Hello, hackers!
initdb on my windows 10 system stopped working after the commit
c5cb8f3b: "Provide lstat() for Windows."
The error message is: creating directory C:/HOME/data ... initdb:
error: could not create directory "C:/HOME": File exists
"C:/HOME" is the junction point to the second volume on my hard drive -
"\??\Volume{GUID}\" which name pgreadlink() erroneously strips here:
https://github.com/postgres/postgres/blob/7e29a79a46d30dc236d097825ab849158929d977/src/port/dirmod.c#L357.
So initdb could not stat the file with name "Volume{GUID}", tried to
create it and failed.
With the attached patch initdb works fine again.
--
regards,
Roman
Attachment | Content-Type | Size |
---|---|---|
dirmod.c.patch | text/x-diff | 514 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2022-08-08 08:33:22 | Re: logical decoding and replication of sequences |
Previous Message | Amit Langote | 2022-08-08 07:38:44 | Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size |