On Wed, Jun 06, 2018 at 09:58:34AM +0530, Amit Kapila wrote:
> On Wed, Jun 6, 2018 at 8:28 AM, Michael Paquier <michael@paquier.xyz> wrote:
>> Ouch. Including directly c.h as you do here is against project policy
>> code. See recent commit a72f0365 for example. pgwin32_open() is
>> visibly able to handle frontend code if I read this code correctly, so
>> could we just remove the "#ifndef FRONTEND" restriction?
>
> I think we need to explore a bit, if we want to remove that, for example
> some of the frontend modules (like pg_receivewal, pg_recvlogical) call two
> argument open which would require change.
Yeah, sure. I am not saying that this is straight-forward, but it may
be worth the switch in the long term. What I am sure about is that the
proposed patch is simple, but that does not look like a correct
approach to me as other tools may benefit from it.
>> It could be
>> risky for existing callers of open() for tool maintainers, or on the
>> contrary people could welcome a wrapper of open() which is
>> concurrent-safe in their own tools.
>
> I am not sure if we can safely assume that because using these functions
> would allow users to concurrently delete the files, but may be it is okay
> for all the FRONTEND modules. One another alternative could be that we
> define open as pgwin32_open (for WIN32) wherever we need it.
Which is what basically happens on any *nix platform, are you foreseeing
anything bad here? Windows has the characteristic in being particular
in everything, which is its main characteristic, so I may be missing
something of course.
--
Michael