On Thu, Jun 18, 2020 at 9:02 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > Yes, I have made the changes. Basically, now I am only using the > XLOG_XACT_INVALIDATIONS for generating all the invalidation messages. > So whenever we are getting the new set of XLOG_XACT_INVALIDATIONS, we > are directly appending it to the txn->invalidations. I have tested > the XLOG_INVALIDATIONS part but while sending this mail I realized > that we could write some automated test for the same. >
Can you share how you have tested it? > I will work on > that soon. > Cool, I think having a regression test for this will be a good idea. @@ -2012,8 +2014,6 @@ ReorderBufferForget(ReorderBuffer *rb, TransactionId xid, XLogRecPtr lsn) if (txn->base_snapshot != NULL && txn->ninvalidations > 0) ReorderBufferImmediateInvalidation(rb, txn->ninvalidations, txn->invalidations); - else - Assert(txn->ninvalidations == 0); Why this Assert is removed? Apart from above, I have made a number of changes in 0002-WAL-Log-invalidations-at-command-end-with-wal_le to remove some unnecessary changes, edited comments, ran pgindent and updated the commit message. If you are fine with these changes, then do include them in your next version. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
v28-0001-Immediately-WAL-log-subtransaction-and-top-level.amit.patch
Description: Binary data
v28-0002-WAL-Log-invalidations-at-command-end-with-wal_le.amit.patch
Description: Binary data