Re: Duplicated LSN in ReorderBuffer
От | Alvaro Herrera from 2ndQuadrant |
---|---|
Тема | Re: Duplicated LSN in ReorderBuffer |
Дата | |
Msg-id | 20190910201105.GA30160@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Duplicated LSN in ReorderBuffer (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Duplicated LSN in ReorderBuffer
|
Список | pgsql-hackers |
Hello, On 2019-Sep-06, Andres Freund wrote: > On 2019-08-19 08:51:43 -0700, Andres Freund wrote: > > On August 19, 2019 7:43:28 AM PDT, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > > >Never mind. I was able to reproduce it later, and verify that Andres' > > >proposed strategy doesn't seem to fix the problem. I'm going to study > > >the problem again today. > > > > Could you post the patch? Here's a couple of patches. always_decode_assignment.patch is Masahiko Sawada's patch, which has been confirmed to fix the assertion failure. assign-child.patch is what I understood you were proposing -- namely to assign the subxid to the top-level xid on NEW_CID. In order for it to work at all, I had to remove a different safety check; but the assertion still hits when running Ildar's test case. So the patch doesn't actually fix anything. And I think it makes sense that it fails, since the first thing that's happening in this patch is that we create both the top-level xact and the subxact with the same LSN value, which is what triggers the assertion in the first place. It's possible that I misunderstood what you were suggesting. If you want to propose a different fix, be my guest, but failing that I'm inclined to push always_decode_assignment.patch sometime before the end of the week. Thanks, -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: