On Fri, Jun 8, 2018 at 1:53 PM, Simon Riggs <si...@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(). >
-StandbyReleaseOldLocks(int nxids, TransactionId *xids) +StandbyReleaseOldLocks(TransactionId oldxid) { ListCell *cell, *prev, @@ -741,26 +741,8 @@ StandbyReleaseOldLocks(int nxids, TransactionId *xids) if (StandbyTransactionIdIsPrepared(lock->xid)) remove = false; - else - { - int i; - bool found = false; - - for (i = 0; i < nxids; i++) - { - if (lock->xid == xids[i]) - { - found = true; - break; - } - } - - /* - * If its not a running transaction, remove it. - */ - if (!found) - remove = true; - } + else if (TransactionIdPrecedes(lock->xid, oldxid)) + remove = true; 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. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com