Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
От | Amit Kapila |
---|---|
Тема | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions |
Дата | |
Msg-id | CAA4eK1+XMz8ywbxbHJ2M0D27kvT3Zb9BMez8wcjuW9O4GU0G5Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
|
Список | pgsql-hackers |
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? 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.
Вложения
В списке pgsql-hackers по дате отправления: