On Tue, Aug 4, 2020 at 12:42 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > On Tue, Aug 4, 2020 at 10:12 AM Amit Kapila <amit.kapil...@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? 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. -- With Regards, Amit Kapila.
v46-0001-Implement-streaming-mode-in-ReorderBuffer.patch
Description: Binary data
