You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
Fix a recently-introduced race condition in LISTEN/NOTIFY handling.
Commit566372b fixed some race conditions involving concurrentSimpleLruTruncate calls, but it introduced new ones in async.c.A newly-listening backend could attempt to read Notify SLRU pages thatwere in process of being truncated, possibly causing an error. Also,the QUEUE_TAIL pointer could become set to a value that's not equal tothe queue position of any backend. While that's fairly harmless inv13 and up (thanks to commit51004c7), in older branches it resultedin near-permanent disabling of the queue truncation logic, so thatcontinued use of NOTIFY led to queue-fill warnings and eventualinability to send any more notifies. (A server restart is enough tomake that go away, but it's still pretty unpleasant.)The core of the problem is confusion about whether QUEUE_TAILrepresents the "logical" tail of the queue (i.e., the oldeststill-interesting data) or the "physical" tail (the oldest data we'venot yet truncated away). To fix, split that into two variables.QUEUE_TAIL regains its definition as the logical tail, and weintroduce a new variable to track the oldest un-truncated page.Per report from Mikael Gustavsson. Like the previous patch,back-patch to all supported branches.Discussion:https://postgr.es/m/1b8561412e8a4f038d7a491c8b922788@smhi.se