From: Petr Jelinek <petr.jelinek@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Andres Freund <andres@anarazel.de>
Cc: Andreas Seltenreich <seltenreich@gmx.de>
Cc: pgsql-hackers@postgresql.org, Michael Paquier <michael.paquier@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Petr Jelinek <petr@2ndquadrant.com>
Subject: Re: [sqlsmith] stuck spinlock in pg_stat_get_wal_receiver after OOM
Date: Tue, 3 Oct 2017 20:32:22 +0200
Message-ID: <4689c67f-5ffb-7359-a3e9-4abf3908e603@2ndquadrant.com> (raw)
In-Reply-To: <23454.1507052652@sss.pgh.pa.us>
References: <20171003145023.nc2ffduj3qvy4b5b@alvherre.pgsql>
<22735.1507048202@sss.pgh.pa.us>
<6526.1507049903@sss.pgh.pa.us>
<23454.1507052652@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 03/10/17 19:44, Tom Lane wrote:
> I wrote:
>>> So that's trouble waiting to happen, for sure. At the very least we
>>> need to do a single fetch of WalRcv->latch, not two. I wonder whether
>>> even that is sufficient, though: this coding requires an atomic fetch of
>>> a pointer, which is something we generally don't assume to be safe.
>
> BTW, I had supposed that this bug was of long standing, but actually it's
> new in v10, dating to 597a87ccc9a6fa8af7f3cf280b1e24e41807d555. Before
> that walreceiver start/stop just changed the owner of a long-lived shared
> latch, and there was no question of stale pointers.
>
> I considered reverting that decision, but the reason for it seems to have
> been to let libpqwalreceiver.c manipulate MyProc->procLatch rather than
> having to know about a custom latch. That's probably a sufficient reason
> to justify some squishiness in the wakeup logic. Still, we might want to
> revisit it if we find any other problems here.
That's correct, and because the other users of that library don't have
special latch it seemed feasible to standardize on the procLatch. If we
indeed wanted to change the decision about this I think we can simply
give latch as a parameter to libpqrcv_connect and store it in the
WalReceiverConn struct. The connection does not need to live past the
latch (although it currently does, but that's just a matter of
reordering the code in WalRcvDie() a little AFAICS).
--
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-hackers@postgresql.org
Cc: petr.jelinek@2ndquadrant.com, tgl@sss.pgh.pa.us, alvherre@alvh.no-ip.org, andres@anarazel.de, seltenreich@gmx.de, michael.paquier@gmail.com, peter.eisentraut@2ndquadrant.com, petr@2ndquadrant.com
Subject: Re: [sqlsmith] stuck spinlock in pg_stat_get_wal_receiver after OOM
In-Reply-To: <4689c67f-5ffb-7359-a3e9-4abf3908e603@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