Re: psql client does not handle WSAEWOULDBLOCK on Windows - Mailing list pgsql-hackers

From Tom Lane
Subject Re: psql client does not handle WSAEWOULDBLOCK on Windows
Date
Msg-id 592101.1756828301@sss.pgh.pa.us
Whole thread Raw
In response to psql client does not handle WSAEWOULDBLOCK on Windows  (Ning <ning94803@gmail.com>)
List pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> This is going to require some platform-specific check that I don't
> have with me, though I am ready to accept that what you are telling
> here is true and that we should apply this macro.  Could somebody
> check that a bit more in depth?  Andrew D. perhaps?

> One thing that I don't understand is why does this only apply after
> the first call of pqsecure_raw_read() in gss_read()?  There is a
> second call of pqsecure_raw_read() you are not covering but it would
> surely need the same treatment, no?

> Also, what about pqsecure_raw_write() in pqsecure_open_gss()?
> Shouldn't the same check apply?

Yeah, I think we pretty much need to use SOCK_ERRNO, SOCK_ERRNO_SET,
and SOCK_STRERROR (if relevant) throughout fe-secure-gssapi.c.
Directly using errno is correct for syscalls related to the file
system, but I think everything in this file is dealing with
socket-related errors.  Certainly the underlying pqsecure_raw_read
and pqsecure_raw_write layer expects those macros to be used.

Like you, I'm not really in a position to test this on Windows ...

            regards, tom lane



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Improve LWLock tranche name visibility across backends
Next
From: Nathan Bossart
Date:
Subject: Re: Use bool with synced field (src/include/replication/slot.h)