From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Patch to improve performance of replay of AccessExclusiveLock |
Date: | 2017-03-18 08:53:40 |
Message-ID: | CANP8+jKoWufLvNvhdJUxqFmRPLyRq0N9=_DFp33j2UMZnzO=OA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 16 March 2017 at 19:08, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Thu, Mar 16, 2017 at 6:01 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> On 8 March 2017 at 10:02, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
>>> On 8 March 2017 at 01:13, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>>> Don't understand this. I'm talking about setting a flag on
>>>> commit/abort WAL records, like the attached.
>>>
>>> There's nothing setting a flag in the attached. I only see the
>>> checking of the flag.
>>
>> Yeh, it wasn't a full patch, just a way marker to the summit for you.
>>
>>>> We just need to track info so we can set the flag at EOXact and we're done.
>>>
>>> Do you have an idea where to store that information? I'd assume we'd
>>> want to store something during LogAccessExclusiveLocks() and check
>>> that in XactLogCommitRecord() and XactLogAbortRecord(). I don't see
>>> anything existing which might help with that today. Do you think I
>>> should introduce some new global variable for that? Or do you propose
>>> calling GetRunningTransactionLocks() again while generating the
>>> Commit/Abort record?
>>
>> Seemed easier to write it than explain further. Please see what you think.
>>
>
> @@ -5563,7 +5575,8 @@ xact_redo_abort(xl_xact_parsed_abort *parsed,
> TransactionId xid)
> /*
> * Release locks, if any. There are no invalidations to send.
> */
> - StandbyReleaseLockTree(xid, parsed->nsubxacts, parsed->subxacts);
> + if (parsed->xinfo & XACT_XINFO_HAS_AE_LOCKS)
> + StandbyReleaseLockTree(xid, parsed->nsubxacts, parsed->subxacts);
>
>
> The patch uses XACT_XINFO_HAS_AE_LOCKS during abort replay, but during
> normal operation (XactLogAbortRecord()), it doesn't seem to log the
> information. Is this an oversight or do you have some reason for
> doing so?
Good catch, thanks. Yes, I changed my mind on whether it was needed
during implementation.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2017-03-18 08:59:11 | Re: Patch to improve performance of replay of AccessExclusiveLock |
Previous Message | Simon Riggs | 2017-03-18 08:52:14 | Re: Patch to improve performance of replay of AccessExclusiveLock |