On Thu, Mar 16, 2017 at 6:01 AM, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 8 March 2017 at 10:02, David Rowley <david.row...@2ndquadrant.com> wrote:
>> On 8 March 2017 at 01:13, Simon Riggs <si...@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?

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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to