Re: hot_standby_feedback vs excludeVacuum and snapshots - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: hot_standby_feedback vs excludeVacuum and snapshots
Date
Msg-id CANP8+jLiK_0Cbnm39FeWCUZ2b+aNJEUSUPL6LvWmYdgjCtScmw@mail.gmail.com
Whole thread Raw
In response to Re: hot_standby_feedback vs excludeVacuum and snapshots  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: hot_standby_feedback vs excludeVacuum and snapshots
List pgsql-hackers
On 8 June 2018 at 11:33, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Fri, Jun 8, 2018 at 1:53 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>
>> So the attached patch fixes both the bug in the recent commit and the
>> one I just found by observation of 49bff5300d527, since they are
>> related.
>>
>> StandbyReleaseOldLocks() can sweep in the same way as
>> ExpireOldKnownAssignedTransactionIds().
>>
>

> How will this avoid the bug introduced by your recent commit
> (32ac7a11)?  After that commit, we no longer consider vacuum's xid in
> RunningTransactions->oldestRunningXid calculation, so it is possible
> that we still remove/release its lock on standby earlier than
> required.

In the past, the presence of an xid was required to prevent removal by
StandbyReleaseOldLocks().

The new patch removes that requirement and removes when the xid is
older than oldestxid

The normal path of removal is at commit or abort,
StandbyReleaseOldLocks is used almost never (as originally intended).

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Concurrency bug in UPDATE of partition-key
Next
From: Surafel Temesgen
Date:
Subject: ON CONFLICT DO NOTHING on pg_dump