Re: Patch to improve performance of replay of AccessExclusiveLock

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?

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com