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=1bE4v93cSH2ZQXYkWKhTnuq6G14QaKcL=b3YwzN6nkOA@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  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
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?

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


pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: documentation about explicit locking
Next
From: Etsuro Fujita
Date:
Subject: Re: Expression errors with "FOR UPDATE" and postgres_fdw with partitionwise join enabled.