Re: Duplicated LSN in ReorderBuffer
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Thomas Munro <thomas.munro@gmail.com>, Ildar Musin <ildar@adjust.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Andres Freund <andres@anarazel.de>
Date: 2019-07-26T22:46:35Z
Lists: pgsql-hackers
Attachments
On 2019-Jul-09, Masahiko Sawada wrote: > I think the cause of this bug would be that a ReorderBufferTXN entry > of sub transaction is created as top-level transaction. And this > happens because we skip to decode ASSIGNMENT during the state of > snapshot builder < SNAPBUILD_FULL. That explanation seems to make sense. > Instead, I wonder if we can decode ASSIGNMENT even when the state of > snapshot builder < SNAPBUILD_FULL_SNAPSHOT. That way, the > ReorderBufferTXN entries of both top transaction and sub transaction > are created properly before we decode NEW_CID. Yeah, that seems a sensible remediation to me. I would reduce the scope a little bit -- only create the assignment in the BUILDING state, and skip it in the START state. I'm not sure that it's possible to get assignments while in START state that are significant (I'm still trying to digest SnapBuildFindSnapshot). I would propose the attached. Andres, do you have an opinion on this? -- Á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