Horton

Re: [sqlsmith] stuck spinlock in pg_stat_get_wal_receiver after OOM

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Andres Freund <andres@anarazel.de>, Andreas Seltenreich <seltenreich@gmx.de>, pgsql-hackers@postgresql.org, Michael Paquier <michael.paquier@gmail.com>
Date: 2017-10-03T16:58:23Z
Lists: pgsql-hackers

Attachments

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.
>
> I'm inclined to think that it'd be a good idea to move the set and
> clear of the latch field into the nearby spinlock critical sections,
> and then change WalRcvForceReply to look like ...

Concretely, as per the attached.

I reordered the WalRcvData fields to show that the "latch" field is now
treated as protected by the spinlock.  In the back branches, we shouldn't
do that, just in case some external code is touching the mutex field.

			regards, tom lane

Commits

  1. Fix race condition with unprotected use of a latch pointer variable.

  2. Fix coding rules violations in walreceiver.c

  3. Use latch instead of select() in walreceiver