Re: BUG #18055: logical decoding core on AllocateSnapshotBuilder()

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>

To: Masahiko Sawada <sawada.mshk@gmail.com>

Cc: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, Amit Kapila <amit.kapila16@gmail.com>, "ocean_li_996@163.com" <ocean_li_996@163.com>, "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>

Date: 2023-08-21T18:19:26Z

Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Fix uninitialized access to InitialRunningXacts during decoding after ERROR.
- c7256e6564fa 15.5 landed
- f7d25117ba87 14.10 landed
- c570bb4d61b6 13.13 landed
- 7e57208ed51a 12.17 landed
- feb4e218e5f9 11.22 landed

Hi,

On 2023-08-21 21:41:46 +0900, Masahiko Sawada wrote:
> On Mon, Aug 21, 2023 at 6:05 AM Andres Freund <andres@anarazel.de> wrote:
> >
> > Hi,
> >
> >
> > I think the real problem is that 272248a0c added InitialRunningXacts a global
> > variable. If it just lived in in struct SnapBuild, this whole thing wouldn't
> > be an issue? The commit justified this choice with avoiding an ABI breakage -
> > but isn't that bogus? The struct is private to snapbuild.c. It doesn't live on
> > disk (that's SnapBuildOnDisk).
> 
> No, since SnapBuildOnDisk contains SnapBuild, if we add something to
> SnapBuild, the on-disk format compatibility would break. See:

Err, yes. That was a brainfart on my part. But we could still just have
handled that via the 'version' field.

Greetings,

Andres Freund