From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: hot_standby_feedback vs excludeVacuum and snapshots |
Date: | 2018-06-08 11:57:11 |
Message-ID: | CANP8+jLiK_0Cbnm39FeWCUZ2b+aNJEUSUPL6LvWmYdgjCtScmw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 8 June 2018 at 11:33, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Fri, Jun 8, 2018 at 1:53 PM, Simon Riggs <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | mariusz | 2018-06-08 12:04:36 | Re: Code of Conduct plan |
Previous Message | Dilip Kumar | 2018-06-08 11:14:39 | Re: Concurrency bug in UPDATE of partition-key |