From: Petr Jelinek <petr.jelinek@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver
Date: Thu, 16 Mar 2017 13:00:54 +0100
Message-ID: <5eff6c57-eaca-c721-339b-3b621d87ce75@2ndquadrant.com> (raw)
In-Reply-To: <7295.1489596949@sss.pgh.pa.us>
References: <E1cjo1g-0000mr-ST@gemulon.postgresql.org>
<19403.1488586564@sss.pgh.pa.us>
<34d98fbf-9195-04d2-b85a-634d6952ffdf@2ndquadrant.com>
<19815.1488600693@sss.pgh.pa.us>
<091deea0-75f2-cfda-ee8c-424162852084@2ndQuadrant.com>
<7295.1489596949@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 15/03/17 17:55, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>> On 03/03/2017 11:11 PM, Tom Lane wrote:
>>> Yeah, I was wondering if this is just exposing a pre-existing bug.
>>> However, the "normal" path operates by repeatedly invoking PQconnectPoll
>>> (cf. connectDBComplete) so it's not immediately obvious how such a bug
>>> would've escaped detection.
>
>> (After a long period of fruitless empirical testing I turned to the code)
>> Maybe I'm missing something, but connectDBComplete() handles a return of
>> PGRESS_POLLING_OK as a success while connectDBStart() seems not to. I
>> don't find anywhere in our code other than libpqwalreceiver that
>> actually uses that interface, so it's not surprising if it's now
>> failing. So my bet is it is indeed a long-standing bug.
>
> Meh ... that argument doesn't hold water, because the old code here called
> PQconnectdbParams which is just PQconnectStartParams then
> connectDBComplete. So the problem cannot be in connectDBStart; that's
> common to both paths. It has to be some discrepancy between what
> connectDBComplete does and what the new loop in libpqwalreceiver is doing.
>
> The original loop coding in 1e8a85009 was not very close to the documented
> spec for PQconnectPoll at all, and while e434ad39a made it closer, it's
> still not really the same: connectDBComplete doesn't call PQconnectPoll
> until the socket is known read-ready or write-ready. The walreceiver loop
> does not guarantee that, but would make an additional call after any
> random other wakeup. It's not very clear why bowerbird, and only
> bowerbird, would be seeing such wakeups --- but I'm having a really hard
> time seeing any other explanation for the change in behavior. (I wonder
> whether bowerbird is telling us that WaitLatchOrSocket can sometimes
> return prematurely on Windows.)
>
> I'm also pretty sure that the ResetLatch call is in the wrong place which
> could lead to missed wakeups, though that's the opposite of the immediate
> problem.
>
> I'll try correcting these things and we'll see if it gets any better.
>
Looks like that didn't help either.
I setup my own Windows machine and can reproduce the issue. I played
around a bit and could not really find a fix other than adding
WL_TIMEOUT and short timeout to WaitLatchOrSocket (it does wait a very
long time on the WaitLatchOrSocket otherwise before failing).
So I wonder if this is the same issue that caused us using different
coding for WaitLatchOrSocket in pgstat.c (lines ~3918-3940).
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: petr.jelinek@2ndquadrant.com, tgl@sss.pgh.pa.us, andrew.dunstan@2ndquadrant.com, peter.eisentraut@2ndquadrant.com, pgsql-hackers@postgreSQL.org
Subject: Re: [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver
In-Reply-To: <5eff6c57-eaca-c721-339b-3b621d87ce75@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox