Re: hot_standby_feedback vs excludeVacuum and snapshots

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, 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-08-04 02:09:18
Message-ID: CAEepm=1gwba8AKKb6BPp5iTdVxf=DeX1qHpHxGDRVt76ZvTwYA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 9, 2018 at 6:51 AM, Noah Misch <noah(at)leadboat(dot)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(dot)munro(at)enterprisedb(dot)com> wrote:
>> > On Thu, Jul 5, 2018 at 8:27 AM, Noah Misch <noah(at)leadboat(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Shay Rojansky 2018-08-04 06:03:47 Re: Stored procedures and out parameters
Previous Message Peter Geoghegan 2018-08-03 22:42:22 Re: Ideas for a relcache test mode about missing invalidations