| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "ocean_li_996(at)163(dot)com" <ocean_li_996(at)163(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #18055: logical decoding core on AllocateSnapshotBuilder() |
| Date: | 2023-08-21 18:19:26 |
| Message-ID: | 20230821181926.gdattedbqt5qspng@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi,
On 2023-08-21 21:41:46 +0900, Masahiko Sawada wrote:
> On Mon, Aug 21, 2023 at 6:05 AM Andres Freund <andres(at)anarazel(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2023-08-21 18:27:32 | Re: BUG #18055: logical decoding core on AllocateSnapshotBuilder() |
| Previous Message | Tom Lane | 2023-08-21 16:30:22 | Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm() |