Re: Duplicated LSN in ReorderBuffer
Masahiko Sawada <sawada.mshk@gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>, 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-08-19T08:42:47Z
Lists: pgsql-hackers
On Tue, Aug 13, 2019 at 6:36 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > > On 2019-Aug-07, Andres Freund wrote: > > > I think we would need to do this for all values of > > SnapBuildCurrentState() - after all the problem occurs because we > > *previously* didn't assign subxids to the toplevel xid. Compared to the > > cost of catalog changes, ReorderBufferAssignChild() is really cheap. So > > I don't think there's any problem just calling it unconditionally (when > > top_xid <> xid, of course). > > BTW I wrote the code as suggested and it passes all the tests ... but I > then noticed that the unpatched code doesn't fail Ildar's original > pgbench-based test for me, either. So maybe my laptop is not powerful > enough to reproduce it, or maybe I'm doing something wrong. If you share the patch fixing this issue I'll test it on my environment where I could reproduce the original problem. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
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