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

From Thomas Munro
Subject Re: hot_standby_feedback vs excludeVacuum and snapshots
Date
Msg-id CAEepm=1gwba8AKKb6BPp5iTdVxf=DeX1qHpHxGDRVt76ZvTwYA@mail.gmail.com
Whole thread Raw
In response to Re: hot_standby_feedback vs excludeVacuum and snapshots  (Noah Misch <noah@leadboat.com>)
Responses Re: hot_standby_feedback vs excludeVacuum and snapshots
List pgsql-hackers
On Mon, Jul 9, 2018 at 6:51 AM, Noah Misch <noah@leadboat.com> wrote:
> On Fri, Jul 06, 2018 at 04:32:56PM +0100, Simon Riggs wrote:
>> On 6 July 2018 at 03:30, Thomas Munro <thomas.munro@enterprisedb.com> wrote:
>> > On Thu, Jul 5, 2018 at 8:27 AM, Noah Misch <noah@leadboat.com> wrote:
>> >>>     However, 49bff5300d527 also introduced a similar bug where subtransaction
>> >>>     commit would fail to release an AccessExclusiveLock, leaving the lock to
>> >>>     be removed sometimes early and sometimes late. This commit fixes
>> >>>     that bug also. Backpatch to PG10 needed.
>> >>
>> >> Subtransaction commit is too early to release an arbitrary
>> >> AccessExclusiveLock.  The primary releases every AccessExclusiveLock at
>> >> top-level transaction commit, top-level transaction abort, or subtransaction
>> >> abort.  CommitSubTransaction() doesn't do that; it transfers locks to the
>> >> parent sub(xact).  Standby nodes can't safely remove an arbitrary lock earlier
>> >> than the primary would.
>> >
>> > But we don't release locks acquired by committing subxacts until the
>> > top level xact commits.  Perhaps that's what the git commit message
>> > meant by "early", as opposed to "late" meaning when
>> > StandbyReleaseOldLocks() next runs because an XLOG_RUNNING_XACTS
>> > record is replayed?
>>
>> Locks held by subtransactions were not released at the correct timing
>> of top-level commit; they are now.
>
> I read the above-quoted commit message as saying that the commit expands the
> set of locks released when replaying subtransaction commit.  The only lock
> that should ever be released at subxact commit is the subxact XID lock.  If
> that continues to be the only lock released at subxact commit, good.

You can still see these "late" lock releases on 10, since the above
quoted commit (15378c1a) hasn't been back-patched yet:

CREATE TABLE foo ();

BEGIN; SAVEPOINT s; LOCK foo; COMMIT;

An AccessExclusiveLock is held on the standby until the next
XLOG_RUNNING_XACTS comes along, up to LOG_SNAPSHOT_INTERVAL_MS = 15
seconds later.

Does anyone know why StandbyReleaseLocks() releases all locks if
passed InvalidTransactionId?  When would that happen?

-- 
Thomas Munro
http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Ideas for a relcache test mode about missing invalidations
Next
From: Shay Rojansky
Date:
Subject: Re: Stored procedures and out parameters