Replication to Postgres 10 on Windows is broken

From: pgsql-bugs-owner@postgresql.org [mailto:pgsql-bugs-owner@postgresql.org] On Behalf Of Augustine, Jobin
Sent: Friday, August 04, 2017 1:54 AM
To: pgsql-bugs@postgresql.org
Subject: [BUGS] Replication to Postgres 10 on Windows is broken

Attention: This email was sent from someone outside of Perceptron. Always exercise caution when opening attachments or clicking links from unknown senders or when receiving unexpected emails.

Summary:
Replica / Slave on Windows fails to conenct to Master.

Scenario:
Master: PostgreSQL 10 (beta1,beta2), Any OS (Linux, Windows, Mac)
Slave : PostgreSQL 10 (beta1,beta2), Windows (Any MS Windows OS)
Slave must be on Windows Machine running on a different server than the Master

Steps to reproduce:
1. Setup a Postgres 10betaX master database can be on any platform (Linux/Windows/Mac)
2. Try to setup a streaming replica on any of the MS Windows running a different Server than the master
(replication within the same server works!)

Error in Postgres logs:
Lines like below keep repeating in Slave side postgres log
----------------------
2017-08-03 10:49:41 UTC [2108]: [1-1] user=,db=,app=,client= FATAL: could not connect to the primary server: could not send data to server: Socket is not connected (0x00002749/10057)
could not send SSL negotiation packet: Socket is not connected (0x00002749/10057)
2017-08-03 10:49:45 UTC [3600]: [1-1] user=,db=,app=,client= FATAL: could not connect to the primary server: could not send data to server: Socket is not connected (0x00002749/10057)
could not send SSL negotiation packet: Socket is not connected (0x00002749/10057)
2017-08-03 10:49:50 UTC [4832]: [1-1] user=,db=,app=,client= FATAL: could not connect to the primary server: could not send data to server: Socket is not connected (0x00002749/10057)
could not send SSL negotiation packet: Socket is not connected (0x00002749/10057)
-------------------------

Additional Information:
Stand alone tools like psql, pg_basebackup, pg_recivewal etc are successful in connecting to primary server and perform their functionalities.
Postgres 9.6 replication works fine across same set of servers.
This Windows specific issue reproducible across pg10beta1 and beta2
This is tested and confirmed by multiple people from my team across different Windows versions.

-Jobin Augustine

Using PG10 Beta1 and BETA2 I’m getting the same error:

Socket is not connected (0x00002749/10057)
could not send SSL negotiation packet: Socket is not connected (0x00002749/10057)

with logical replication in Windows environment, when I’m trying to Create Subscription, even though any other connection from Subscriber server to Publisher server works quite fine, for instance there is no errors when using Postgres_fdw to connect from Subscriber server to Publisher server.
I reported this issue on this forum: Bug #14669, but didn’t get any replies.

Must be a common issue between streaming and logical replication in PG10 BETA in Windows environment.
I’d appreciate if someone from 2ndQardrant could take a look at this issue.

Regards,
Igor Neyman

On Fri, Aug 04, 2017 at 11:23:43AM +0530, Augustine, Jobin wrote:

*Summary:*
Replica / Slave on Windows fails to conenct to Master.

*Scenario:*
Master: PostgreSQL 10 (beta1,beta2), Any OS (Linux, Windows, Mac)
Slave : PostgreSQL 10 (beta1,beta2), Windows (Any MS Windows OS)
Slave must be on Windows Machine running on a different server than the
Master

*Steps to reproduce:*
1. Setup a Postgres 10betaX master database can be on any platform
(Linux/Windows/Mac)
2. Try to setup a streaming replica on any of the MS Windows running a
different Server than the master

I've added this as an open item. Confirmed in this setup:

-- Server
Debian 9
PostgreSQL 10beta2 from apt.postgresql.org
edit postgresql.conf to allow remote connections
edit pg_hba.conf to allow remote connections
create replication user w/ password

-- Client
Windows Server 2016
postgresql-10.0-beta2-windows-x64-binaries.zip from EnterpriseDB
pg_basebackup -h myserver -D datadir -X stream -R
install ordinary *.conf
postgres -D datadir

Stand alone tools like psql, pg_basebackup, pg_recivewal etc are
successful in connecting to primary server and perform their
functionalities.

I can confirm each of those, too.

I don't, however, see a smoking gun among commits. Would you bisect the
commits since 9.6 and see which one broke things?

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Noah Misch <noah@leadboat.com> writes:

I've added this as an open item. Confirmed in this setup:

-- Client
Windows Server 2016
postgresql-10.0-beta2-windows-x64-binaries.zip from EnterpriseDB

I wonder whether the other complainants were using EDB's build,
and if not, just what were they using. The indirect question is:
what version of OpenSSL is the Windows build using?

I don't, however, see a smoking gun among commits. Would you bisect the
commits since 9.6 and see which one broke things?

Gut instinct says that the reason this case fails when other tools
can connect successfully is that libpqwalreceiver is the only tool
that uses PQconnectStart/PQconnectPoll rather than a plain
PQconnectdb, and that there is some behavioral difference between
connectDBComplete's wait loop and libpqrcv_connect's wait loop that
OpenSSL is sensitive to --- but only on Windows, and maybe only on
particular OpenSSL versions.

I have some memory of having tweaked libpqrcv_connect's loop once
already, but I can't find a commit for that right now.

A different line of thought is that maybe we broke it with the
changes for OpenSSL 1.1.0. Again, it would be very important
to know which OpenSSL version we're dealing with here.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On Sun, Aug 06, 2017 at 11:17:57AM -0400, Tom Lane wrote:

Noah Misch <noah@leadboat.com> writes:

I've added this as an open item. Confirmed in this setup:

-- Client
Windows Server 2016
postgresql-10.0-beta2-windows-x64-binaries.zip from EnterpriseDB

I wonder whether the other complainants were using EDB's build,
and if not, just what were they using. The indirect question is:
what version of OpenSSL is the Windows build using?

Those binaries I used have OpenSSL 1.0.2l.

I don't, however, see a smoking gun among commits. Would you bisect the
commits since 9.6 and see which one broke things?

Gut instinct says that the reason this case fails when other tools
can connect successfully is that libpqwalreceiver is the only tool
that uses PQconnectStart/PQconnectPoll rather than a plain
PQconnectdb, and that there is some behavioral difference between
connectDBComplete's wait loop and libpqrcv_connect's wait loop that

That would fit. Until v10 (commit 1e8a850), PQconnectStart() had no in-tree
callers outside of libpq itself.

OpenSSL is sensitive to --- but only on Windows, and maybe only on
particular OpenSSL versions.

The failure is so early, before pgtls_init(), that I doubt OpenSSL version is
a factor.

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

I wrote:

Gut instinct says that the reason this case fails when other tools
can connect successfully is that libpqwalreceiver is the only tool
that uses PQconnectStart/PQconnectPoll rather than a plain
PQconnectdb, and that there is some behavioral difference between
connectDBComplete's wait loop and libpqrcv_connect's wait loop that
OpenSSL is sensitive to --- but only on Windows, and maybe only on
particular OpenSSL versions.

On closer inspection, I take that back. This can't be directly
OpenSSL's fault, because those error messages come out before libpq
has invoked OpenSSL at all; in particular we see

2017-08-03 10:49:41 UTC [2108]: [1-1] user=,db=,app=,client= FATAL: could not connect to the primary server: could not send data to server: Socket is not connected (0x00002749/10057)
could not send SSL negotiation packet: Socket is not connected
(0x00002749/10057)

and "could not send SSL negotiation packet" certainly must occur
before we've asked OpenSSL to do anything.

What seems likely to me at this point is that the changes in
PQconnectPoll() to support multiple hosts are somehow responsible.
It must still be connected to libpqwalreceiver's different wait loop,
but the details are unclear.

It would likely be useful to add some debug logging to PQconnectPoll
to find out what set of addresses it's seeing and whether this failure
occurs after having advanced over some of them.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Noah Misch <noah@leadboat.com> writes:

On Sun, Aug 06, 2017 at 11:17:57AM -0400, Tom Lane wrote:

Gut instinct says that the reason this case fails when other tools
can connect successfully is that libpqwalreceiver is the only tool
that uses PQconnectStart/PQconnectPoll rather than a plain
PQconnectdb, and that there is some behavioral difference between
connectDBComplete's wait loop and libpqrcv_connect's wait loop that

That would fit. Until v10 (commit 1e8a850), PQconnectStart() had no in-tree
callers outside of libpq itself.

Yeah. After some digging around I think I see exactly what is happening.
The error message would be better read as "Socket is not connected *yet*",
that is, the problem is that we're trying to write data before the
nonblocking connection request has completed. (This fits with the OP's
observation that local loopback connections work fine --- they probably
complete immediately.) PQconnectPoll believes that it just has to wait
for write-ready when waiting for a connection to complete. When using
connectDBComplete's wait loop, that reduces to a call to Windows' version
of select(2), in pqSocketPoll, and according to

https://msdn.microsoft.com/en-us/library/windows/desktop/ms740141(v=vs.85).aspx

"The parameter writefds identifies the sockets that are to be checked for
writability. If a socket is processing a connect call (nonblocking), a
socket is writeable if the connection establishment successfully
completes."

On the other hand, in libpqwalreceiver, we're depending on latch.c's
implementation, and it uses WSAEventSelect's FD_WRITE event:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms741576(v=vs.85).aspx

If I'm reading that correctly, FD_WRITE is set instantly by the connect
request, probably even in the nonblock case, and it only gets cleared
by a failed write request. It looks to me like we would have to
specifically look for FD_CONNECT, *not* FD_WRITE, to make this work.

This is problematic, because the APIs in between don't provide a way
to report that we're still waiting for connect rather than for
data-write-ready. Anybody have the stomach for extending PQconnectPoll's
API with an extra PGRES_POLLING_CONNECTING state? If not, can we tell in
WaitEventAdjustWin32 that the socket is still connecting and we must
substitute FD_CONNECT for FD_WRITE?

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Hi,

On 2017-08-06 12:29:07 -0400, Tom Lane wrote:

Yeah. After some digging around I think I see exactly what is happening.
The error message would be better read as "Socket is not connected *yet*",
that is, the problem is that we're trying to write data before the
nonblocking connection request has completed. (This fits with the OP's
observation that local loopback connections work fine --- they probably
complete immediately.) PQconnectPoll believes that it just has to wait
for write-ready when waiting for a connection to complete. When using
connectDBComplete's wait loop, that reduces to a call to Windows' version
of select(2), in pqSocketPoll, and according to

https://msdn.microsoft.com/en-us/library/windows/desktop/ms740141(v=vs.85).aspx

"The parameter writefds identifies the sockets that are to be checked for
writability. If a socket is processing a connect call (nonblocking), a
socket is writeable if the connection establishment successfully
completes."

On the other hand, in libpqwalreceiver, we're depending on latch.c's
implementation, and it uses WSAEventSelect's FD_WRITE event:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms741576(v=vs.85).aspx

If I'm reading that correctly, FD_WRITE is set instantly by the connect
request, probably even in the nonblock case, and it only gets cleared
by a failed write request. It looks to me like we would have to
specifically look for FD_CONNECT, *not* FD_WRITE, to make this work.

Nice digging.

This is problematic, because the APIs in between don't provide a way
to report that we're still waiting for connect rather than for
data-write-ready. Anybody have the stomach for extending PQconnectPoll's
API with an extra PGRES_POLLING_CONNECTING state?

I'm a bit hesitant to do so at this phase of the release cycle, it'd
kind of force all users to upgrade their code, and I'm sure there's a
couple out-of-tree ones. And not just code explicitly using new versions
of libpq, also users of old versions - several distributions just
install newer libpq versions and rely on it being compatible.

If not, can we tell in
WaitEventAdjustWin32 that the socket is still connecting and we must
substitute FD_CONNECT for FD_WRITE?

I was wondering, for a second, if we should just always use FD_CONNECT
once in every set. But unfortunately there's plenty places that
create/destroy sets at a high enough speed for that to not be a nice
solution.

A third solution would be to, for v10, add a #ifdef WIN32 block to
libpqrcv_connect() that just waits till FD_CONNECT is ready. That has
the disadvantage of not accepting interrupts, but still seems better
than not working at all. That's not much of a real solution, but this
late in the cycle it might be advisable to hold our noses :(

Greetings,

Andres Freund

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Andres Freund <andres@anarazel.de> writes:

On 2017-08-06 12:29:07 -0400, Tom Lane wrote:

This is problematic, because the APIs in between don't provide a way
to report that we're still waiting for connect rather than for
data-write-ready. Anybody have the stomach for extending PQconnectPoll's
API with an extra PGRES_POLLING_CONNECTING state?

I'm a bit hesitant to do so at this phase of the release cycle,

I'm pretty hesitant to do that at *any* phase of the release cycle,
it's just too likely to break user code.

However, there's always more than one way to skin the cat. What we need
to know is whether PQconnectPoll's state machine is in CONNECTION_STARTED
state, and PQstatus() does expose that, even though it claims it's an
internal state that callers shouldn't rely on. So here's a sketch:

* Invent a separate WL_SOCKET_CONNECTED flag for WaitLatchOrSocket.
On Unix we can treat that the same as WL_SOCKET_WRITEABLE, on Windows
it maps to FD_CONNECT.

* In libpqwalreceiver, do something like

io_flag = (status == PGRES_POLLING_READING
? WL_SOCKET_READABLE
#ifdef WIN32
: PQstatus(conn->streamConn) == CONNECTION_STARTED
? WL_SOCKET_CONNECTED
#endif
: WL_SOCKET_WRITEABLE);

The #ifdef's optional, but no reason to spend extra cycles if we don't
have to. (Not sure if this is adequately parenthesized...)

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Hi,

On 2017-08-06 13:34:42 -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

On 2017-08-06 12:29:07 -0400, Tom Lane wrote:

This is problematic, because the APIs in between don't provide a way
to report that we're still waiting for connect rather than for
data-write-ready. Anybody have the stomach for extending PQconnectPoll's
API with an extra PGRES_POLLING_CONNECTING state?

I'm a bit hesitant to do so at this phase of the release cycle,

I'm pretty hesitant to do that at *any* phase of the release cycle,
it's just too likely to break user code.

Right, that's what I went on to say ;)

However, there's always more than one way to skin the cat. What we need
to know is whether PQconnectPoll's state machine is in CONNECTION_STARTED
state, and PQstatus() does expose that, even though it claims it's an
internal state that callers shouldn't rely on. So here's a sketch:

* Invent a separate WL_SOCKET_CONNECTED flag for WaitLatchOrSocket.
On Unix we can treat that the same as WL_SOCKET_WRITEABLE, on Windows
it maps to FD_CONNECT.

Yea, that should work, and could be useful-ish for things outside of
libpqwalreceiver. E.g. parallel fdw scan, that IIRC somebody is working
on, seems like it very well could run into similar issues if we want to
handle interrupts, which we should...

* In libpqwalreceiver, do something like

io_flag = (status == PGRES_POLLING_READING
? WL_SOCKET_READABLE
#ifdef WIN32
: PQstatus(conn->streamConn) == CONNECTION_STARTED
? WL_SOCKET_CONNECTED
#endif
: WL_SOCKET_WRITEABLE);

The #ifdef's optional, but no reason to spend extra cycles if we don't
have to. (Not sure if this is adequately parenthesized...)

Let's use proper ifs ;)...

Greetings,

Andres Freund

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Hi,

On 2017-08-06 10:48:22 -0700, Andres Freund wrote:

Hi,

On 2017-08-06 13:34:42 -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

On 2017-08-06 12:29:07 -0400, Tom Lane wrote:

This is problematic, because the APIs in between don't provide a way
to report that we're still waiting for connect rather than for
data-write-ready. Anybody have the stomach for extending PQconnectPoll's
API with an extra PGRES_POLLING_CONNECTING state?

I'm a bit hesitant to do so at this phase of the release cycle,

I'm pretty hesitant to do that at *any* phase of the release cycle,
it's just too likely to break user code.

Right, that's what I went on to say ;)

However, there's always more than one way to skin the cat. What we need
to know is whether PQconnectPoll's state machine is in CONNECTION_STARTED
state, and PQstatus() does expose that, even though it claims it's an
internal state that callers shouldn't rely on. So here's a sketch:

* Invent a separate WL_SOCKET_CONNECTED flag for WaitLatchOrSocket.
On Unix we can treat that the same as WL_SOCKET_WRITEABLE, on Windows
it maps to FD_CONNECT.

Yea, that should work, and could be useful-ish for things outside of
libpqwalreceiver. E.g. parallel fdw scan, that IIRC somebody is working
on, seems like it very well could run into similar issues if we want to
handle interrupts, which we should...

* In libpqwalreceiver, do something like

io_flag = (status == PGRES_POLLING_READING
? WL_SOCKET_READABLE
#ifdef WIN32
: PQstatus(conn->streamConn) == CONNECTION_STARTED
? WL_SOCKET_CONNECTED
#endif
: WL_SOCKET_WRITEABLE);

The #ifdef's optional, but no reason to spend extra cycles if we don't
have to. (Not sure if this is adequately parenthesized...)

Let's use proper ifs ;)...

Is anybody working on a patch like this? I can try writing one blindly,
if somebody else tests it. But if somebody natively on windows is
working on it, that's going to be more efficient. It'd be nice to have
something merged by wrap tomorrow...

Greetings,

Andres Freund

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On 2017-08-06 13:07:42 -0700, Andres Freund wrote:

Is anybody working on a patch like this? I can try writing one blindly,
if somebody else tests it. But if somebody natively on windows is
working on it, that's going to be more efficient. It'd be nice to have
something merged by wrap tomorrow...

Here's a prototype patch implementing what Tom outlined. I've compiled
it with mingw under linux, but haven't run it. Could some windows
capable person take this for a spin?

Unfortunately we can't just push this to the BF and see what it says -
our tests don't catch this one... And there's not that much time before
the wrap.

Anybody have an opinion about adding ifs for WL_SOCKET_CONNECTED to
!win32 implementations rather than redefining it to WL_SOCKET_WRITEABLE?

- Andres

Andres Freund <andres@anarazel.de> writes:

Here's a prototype patch implementing what Tom outlined.

This bit is flat wrong:

-		int			io_flag;
+		int			io_flag = WL_POSTMASTER_DEATH | WL_LATCH_SET;

io_flag has to be *just* the I/O condition, because we use it in a test
after the WaitLatchOrSocket call.

Anybody have an opinion about adding ifs for WL_SOCKET_CONNECTED to
!win32 implementations rather than redefining it to WL_SOCKET_WRITEABLE?

I fear it would complicate matters greatly, because you'd have to figure
out which of the two flags to signal back after detecting socket writable.
I think defining it as equal to WL_SOCKET_WRITEABLE is fine.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On 2017-08-06 18:04:49 -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

Here's a prototype patch implementing what Tom outlined.

This bit is flat wrong:

-		int			io_flag;
+		int			io_flag = WL_POSTMASTER_DEATH | WL_LATCH_SET;

io_flag has to be *just* the I/O condition, because we use it in a test
after the WaitLatchOrSocket call.

Hm, right. Wouldn't be particularly consequential, but... I'd actually
consider just removing the if around
/* If socket is ready, advance the libpq state machine */
if (rc & io_flag)
status = PQconnectPoll(conn->streamConn);
the only thing that protects us against is calling PQconnectPoll() when
the latch has been set. Hardly problematic.

Anybody have an opinion about adding ifs for WL_SOCKET_CONNECTED to
!win32 implementations rather than redefining it to WL_SOCKET_WRITEABLE?

I fear it would complicate matters greatly, because you'd have to figure
out which of the two flags to signal back after detecting socket writable.
I think defining it as equal to WL_SOCKET_WRITEABLE is fine.

Well, I'd have said, signal the one(s) back that have been
requested. But I'm ok with the current state, adding a bunch of
pointless branches didn't strike me as worthwhile...

Greetings,

Andres Freund

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Andres Freund <andres@anarazel.de> writes:

On 2017-08-06 18:04:49 -0400, Tom Lane wrote:

io_flag has to be *just* the I/O condition, because we use it in a test
after the WaitLatchOrSocket call.

Hm, right. Wouldn't be particularly consequential,

Yes, it would be. The entire point of this loop is to avoid blocking
in PQconnectPoll, and that's not guaranteed unless we honor the contract
of only calling it when we've gotten the read-ready or write-ready status
it asked for.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On Sun, Aug 06, 2017 at 08:50:37AM -0700, Noah Misch wrote:

On Sun, Aug 06, 2017 at 11:17:57AM -0400, Tom Lane wrote:

Noah Misch <noah@leadboat.com> writes:

I've added this as an open item. Confirmed in this setup:

-- Client
Windows Server 2016
postgresql-10.0-beta2-windows-x64-binaries.zip from EnterpriseDB

I wonder whether the other complainants were using EDB's build,
and if not, just what were they using. The indirect question is:
what version of OpenSSL is the Windows build using?

Those binaries I used have OpenSSL 1.0.2l.

I don't, however, see a smoking gun among commits. Would you bisect the
commits since 9.6 and see which one broke things?

Gut instinct says that the reason this case fails when other tools
can connect successfully is that libpqwalreceiver is the only tool
that uses PQconnectStart/PQconnectPoll rather than a plain
PQconnectdb, and that there is some behavioral difference between
connectDBComplete's wait loop and libpqrcv_connect's wait loop that

That would fit. Until v10 (commit 1e8a850), PQconnectStart() had no in-tree
callers outside of libpq itself.

[Action required within three days. This is a generic notification.]

The above-described topic is currently a PostgreSQL 10 open item. Peter,
since you committed the patch believed to have created it, you own this open
item. If some other commit is more relevant or if this does not belong as a
v10 open item, please let us know. Otherwise, please observe the policy on
open item ownership[1]/messages/by-id/20170404140717.GA2675809@tornado.leadboat.com and send a status update within three calendar days of
this message. Include a date for your subsequent status update. Testers may
discover new open items at any time, and I want to plan to get them all fixed
well in advance of shipping v10. Consequently, I will appreciate your efforts
toward speedy resolution. Thanks.

[1]: /messages/by-id/20170404140717.GA2675809@tornado.leadboat.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 8/7/17 21:06, Noah Misch wrote:

That would fit. Until v10 (commit 1e8a850), PQconnectStart() had no in-tree
callers outside of libpq itself.

[Action required within three days. This is a generic notification.]

The above-described topic is currently a PostgreSQL 10 open item. Peter,
since you committed the patch believed to have created it, you own this open
item.

I don't think I can usefully contribute to this. Could someone else
take it?

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On 2017-08-08 19:25:37 -0400, Peter Eisentraut wrote:

On 8/7/17 21:06, Noah Misch wrote:

That would fit. Until v10 (commit 1e8a850), PQconnectStart() had no in-tree
callers outside of libpq itself.

[Action required within three days. This is a generic notification.]

The above-described topic is currently a PostgreSQL 10 open item. Peter,
since you committed the patch believed to have created it, you own this open
item.

I don't think I can usefully contribute to this. Could someone else
take it?

I've written up a patch at
http://archives.postgresql.org/message-id/20170806215521.d6fq4esvx7s5ejka%40alap3.anarazel.de
but I can't test this either. We really need somebody with access to
window to verify whether it works. That patch needs some adjustments as
remarked by Tom, but can be tested as is.

Regards,

Andres

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Aug 08, 2017 at 07:25:37PM -0400, Peter Eisentraut wrote:

On 8/7/17 21:06, Noah Misch wrote:

That would fit. Until v10 (commit 1e8a850), PQconnectStart() had no in-tree
callers outside of libpq itself.

[Action required within three days. This is a generic notification.]

The above-described topic is currently a PostgreSQL 10 open item. Peter,
since you committed the patch believed to have created it, you own this open
item.

I don't think I can usefully contribute to this. Could someone else
take it?

If nobody volunteers, you could always resolve this by reverting 1e8a850 and
successors.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2017-08-10 18:51:07 -0700, Noah Misch wrote:

On Tue, Aug 08, 2017 at 07:25:37PM -0400, Peter Eisentraut wrote:

On 8/7/17 21:06, Noah Misch wrote:

That would fit. Until v10 (commit 1e8a850), PQconnectStart() had no in-tree
callers outside of libpq itself.

[Action required within three days. This is a generic notification.]

The above-described topic is currently a PostgreSQL 10 open item. Peter,
since you committed the patch believed to have created it, you own this open
item.

I don't think I can usefully contribute to this. Could someone else
take it?

If nobody volunteers, you could always resolve this by reverting 1e8a850 and
successors.

I've volunteered a fix nearby, just can't test it. I don't think we can
require committers to work on windows.

- Andres

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs