On 08/19/2013 11:36 PM, Michael Cronenworth wrote:
On 08/19/2013 07:35 PM, Noah Misch wrote:
That was option #1. (You weren't planning to change just the one symbol
causing the failure at hand, were you?) Reasonable choice. The
point in the
code comment quoted above looks bad, but the lack of reports of that
nature
against official 9.2 binaries corroborates it having not been a
problem yet.
The only non-socket use I see for the constants in question is the
EINTR test
in XLogWrite(), which probably can't happen on Windows.
Redefining compiler constants is bad bandaid. A similar bandaid was in
place to begin with caused this problem. If you believe PostgreSQL
will never use code that needs the true errno value then go ahead with
Option 1.
No the reverse is the case. The real problem is that the bandaid was not
applied sufficiently widely. What we propose is exactly what is already
in use for the Microsoft compilers, and has thus been well and truly
tested over some years.
Changing these definitions doesn't change the value of errno in the
slightest - it only changes the values that we test for.
The caveat in the MSVC-specific code that Noah pointed to still applies,
but it appears that we don't in fact use these constants anywhere other
than in relation to sockets.
I'm about to update my buildfarm member jacana so it has the latest
mingw-w64 compiler and this should exhibit this error. Then I'll apply a
patch along the lines of option 1. If nothing breaks, I'll backpatch
that to 9.1 where we enabled use of this compiler.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
