|From:||Alvaro Herrera from 2ndQuadrant <alvherre(at)alvh(dot)no-ip(dot)org>|
|To:||Andres Freund <andres(at)anarazel(dot)de>|
|Cc:||Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Ildar Musin <ildar(at)adjust(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>|
|Subject:||Re: Duplicated LSN in ReorderBuffer|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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(at)2ndquadrant(dot)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.
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
|Next Message||Alvaro Herrera from 2ndQuadrant||2019-09-10 20:48:22||Re: A problem about partitionwise join|
|Previous Message||Tom Lane||2019-09-10 20:01:32||Re: SIGQUIT on archiver child processes maybe not such a hot idea?|