| 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-07-06 02:30:46 |
| Message-ID: | CAEepm=1bE4v93cSH2ZQXYkWKhTnuq6G14QaKcL=b3YwzN6nkOA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
--
Thomas Munro
http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Etsuro Fujita | 2018-07-06 03:40:08 | Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled. |
| Previous Message | Amit Langote | 2018-07-06 02:00:21 | Re: documentation about explicit locking |