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.