Horton

Re: Race condition in InvalidateObsoleteReplicationSlots()

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Álvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, Fujii Masao <fujii@postgresql.org>
Date: 2021-06-23T14:02:12Z
Lists: pgsql-hackers 
On 2021-Jun-20, Tom Lane wrote:

> Actually ... isn't there a second race, in the opposite direction?
> IIUC, the point of this is that once we force some WAL to be sent
> to the frozen sender/receiver, they'll be killed for failure to
> respond.  But the advance_wal call is not the only possible cause
> of that; a background autovacuum for example could emit some WAL.
> So I fear it's possible for the 'to release replication slot'
> message to come out before we capture $logstart.  I think you
> need to capture that value before the kill not after.

I accounted for all those things and pushed again.

-- 
Álvaro Herrera       Valdivia, Chile
"I can see support will not be a problem.  10 out of 10."    (Simon Wittber)
      (http://archives.postgresql.org/pgsql-general/2004-12/msg00159.php)

Commits

  1. Add test case for obsoleting slot with active walsender, take 2

  2. Add test case for obsoleting slot with active walsender

  3. Return ReplicationSlotAcquire API to its original form

  4. Fix race condition in invalidating obsolete replication slots

  5. Fix issues in invalidation of obsolete replication slots.

  6. Allow users to limit storage reserved by replication slots