On Wed, Aug 5, 2020 at 6:25 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Tue, Aug 4, 2020 at 12:42 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >
> > On Tue, Aug 4, 2020 at 10:12 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> >
> > > 4. I think we can explain the problems (like we can see the wrong
> > > tuple or see two versions of the same tuple or whatever else wrong can
> > > happen, if possible with some example) related to concurrent aborts
> > > somewhere in comments.
> >
> > Done
> >
>
> I have slightly modified the comment added for the above point and
> apart from that added/modified a few comments at other places. I have
> also slightly edited the commit message.
>
> @@ -2196,6 +2778,7 @@ ReorderBufferAddNewTupleCids(ReorderBuffer *rb,
> TransactionId xid,
> change->lsn = lsn;
> change->txn = txn;
> change->action = REORDER_BUFFER_CHANGE_INTERNAL_TUPLECID;
> + change->txn = txn;
>
> This change is not required as the same information is assigned a few
> lines before. So, I have removed this change as well. Let me know
> what you think of the above changes?
Changes look fine to me.
> Can we add a test for incomplete changes (probably with toast
> insertion but we can do it for spec_insert case as well) in
> ReorderBuffer such that it needs to first serialize the changes and
> then stream it? I have manually verified such scenarios but it is
> good to have the test for the same.
I have added a new test for the same in the stream.sql file.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
