Re: Duplicated LSN in ReorderBuffer
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera from 2ndQuadrant <alvherre@alvh.no-ip.org>
To: Andres Freund <andres@anarazel.de>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, Ildar Musin <ildar@adjust.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Petr Jelinek <petr@2ndquadrant.com>, Simon Riggs <simon@2ndquadrant.com>
Date: 2019-09-10T20:11:05Z
Lists: pgsql-hackers
Attachments
- assign-child.patch (text/x-diff) patch
- always_decode_assignment.patch (text/x-diff) patch
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
Commits
-
logical decoding: process ASSIGNMENT during snapshot build
- e8c7f40a1f8a 9.4.25 landed
- bac2fae05c77 13.0 landed
- ae4305f6d303 9.6.16 landed
- 96b5033e1171 12.0 landed
- 7110f5c37721 9.5.20 landed
- 4f7dbf0ef50b 10.11 landed
- 41f3d262693b 11.6 landed
-
Ability to advance replication slots
- 9c7d06d60680 11.0 cited