Re: Replication to Postgres 10 on Windows is broken

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Noah Misch <noah(at)leadboat(dot)com>, "Augustine, Jobin" <jobin(dot)augustine(at)openscg(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Replication to Postgres 10 on Windows is broken
Date: 2017-08-06 20:07:42
Message-ID: 20170806200742.sz6yshtq62ayrpa4@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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(at)anarazel(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Geoghegan 2017-08-06 20:29:05 Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values
Previous Message Peter Geoghegan 2017-08-06 20:06:21 Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2017-08-06 20:29:05 Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values
Previous Message Peter Geoghegan 2017-08-06 20:06:21 Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values