From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(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-07-06 15:32:56 |
Message-ID: | CANP8+jLhXq5Pk6s-dekMMhpZ4n+L4jNb_ptChgREgvv988SOWg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2018-07-06 15:45:46 | Re: BUG #14999: pg_rewind corrupts control file global/pg_control |
Previous Message | Andrew Dunstan | 2018-07-06 15:13:22 | Re: no partition pruning when partitioning using array type |