On Tue, Apr 14, 2020 at 3:57 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Tue, Apr 14, 2020 at 3:41 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > > > > > > > > > > @@ -281,6 +281,24 @@ DecodeXactOp(LogicalDecodingContext *ctx, > > > > XLogRecordBuffer *buf) > > > > } > > > > case XLOG_XACT_ASSIGNMENT: > > > > break; > > > > + case XLOG_XACT_INVALIDATIONS: > > > > + { > > > > + TransactionId xid; > > > > + xl_xact_invalidations *invals; > > > > + > > > > + xid = XLogRecGetXid(r); > > > > + invals = (xl_xact_invalidations *) XLogRecGetData(r); > > > > + > > > > + if (!TransactionIdIsValid(xid)) > > > > + break; > > > > + > > > > + ReorderBufferAddInvalidation(reorder, xid, buf->origptr, > > > > + invals->nmsgs, invals->msgs); > > > > > > > > Why should we insert an WAL record for such cases? > > > > > > > > > > Right, if there is any such case, we should avoid it. > > > > I think we don't have any such case because we are logging at the > > command end. So I have created an assert instead of the check. > > > > Have you tried to ensure this in some way? One idea could be to add > an Assert (to check if transaction id is assigned) in the new code > where you are writing WAL for this action and then run make > check-world and or make installcheck-world.
Yeah, I had already tested that. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com