Re: Patch to improve performance of replay of AccessExclusiveLock
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndquadrant.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: David Rowley <david.rowley@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-03-18T08:53:40Z
Lists: pgsql-hackers
On 16 March 2017 at 19:08, Amit Kapila <amit.kapila16@gmail.com> wrote: > On Thu, Mar 16, 2017 at 6:01 AM, Simon Riggs <simon@2ndquadrant.com> wrote: >> On 8 March 2017 at 10:02, David Rowley <david.rowley@2ndquadrant.com> wrote: >>> On 8 March 2017 at 01:13, Simon Riggs <simon@2ndquadrant.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
Commits
-
Move RecoveryLockList into a hash table.
- a40cff8956e8 11.0 landed
- 35750a38b7ab 9.6.10 landed
- c4ccbcc1a2a1 9.4.19 landed
- 12f7d91994d1 9.3.24 landed
- 7bcda60d41cb 9.5.14 landed
- 88554c091101 10.5 landed