Andrew Dunstan wrote:
Can you narrow down exactly what in that commit broke VS 2010? Are there any compiler warnings?

I was able to nail down the problem.

Running the regression tests (vcregress check) gives the following messages:
============== creating temporary installation        ==============
============== initializing database system           ==============
============== starting postmaster                    ==============

pg_regress: postmaster did not respond within 60 seconds
Examine src/test/regress/log/postmaster.log for the reason

postmaster.log shows the following messages:
LOG:  database system was shut down at 2011-12-28 22:09:46 CET
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started
LOG:  incomplete startup packet
with the line "LOG: incomplete startup packet" repeated several times afterwards.

The problem seems to be related to an invalid socket error constant.
EWOULDBLOCK gets expanded to 140 with commit 1a0c76c32fe470142d3663dd84ac960d75a4e8db applied whereas it got expanded to 10035L before. Adding the following code to src/include/port/win32.h restores the former (running) behaviour :
#if _MSC_VER >= 1600
#pragma warning(disable:4005)

But according to the winsock docs this minimal invasive surgery isn't really appropriate (at least for visual c).

It appears that VS 2010 and Windows SDK 7.1 now have an extended errno.h that defines quite a few of the E* constants:
#define EADDRINUSE      100
#define EADDRNOTAVAIL   101
#define ETXTBSY         139
#define EWOULDBLOCK     140

Here we probably run into the conflict that winsock2.h has always been warning about:
 * Windows Sockets errors redefined as regular Berkeley error constants.
 * These are commented out in Windows NT to avoid conflicts with errno.h.
 * Use the WSA constants instead.
#if 0
#define ESTALE                  WSAESTALE
#define EREMOTE                 WSAEREMOTE

A possible solution would be to use something like PGEWOULDBLOCK and similiar constants wherever socket errors are used and set them to the WSAE* constants on windows and the E* constants on other platforms.

Anyhow, this would be ways beyond the scope of my patch and there will probably be a better solution to be suggested from a real C hacker.



Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to