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>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Petr Jelinek <petr@2ndquadrant.com>
Date: 2017-10-03T17:44:12Z
Lists: pgsql-hackers 
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.

			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