Re: Invalid pointer access in logical decoding after error

From: vignesh C <vignesh21(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Euler Taveira <euler(at)eulerto(dot)com>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Invalid pointer access in logical decoding after error
Date: 2025-10-11 14:19:48
Message-ID: CALDaNm0JsF3UUmP0GToWOaBRRsCmrKS+2o865jEybqJVBD1E1g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 9 Oct 2025 at 23:33, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Thu, Oct 9, 2025 at 10:07 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> > On Thu, Oct 9, 2025 at 8:23 AM Euler Taveira <euler(at)eulerto(dot)com> wrote:
> > >
> > > On Thu, Oct 9, 2025, at 10:40 AM, vignesh C wrote:
> > > > On Thu, 9 Oct 2025 at 00:16, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > > >>
> > > >> One thing we might want to consider is for v14 and v13. They don't
> > > >> have this bug since the entry_ctx was introduced in v15, but it's
> > > >> still true for them that RelationSyncCache is not cleaned up in error
> > > >> cases if pgoutput is used via SQL API. For example, if
> > > >> RelationSyncCache hash table gets corrupted for some reason, logical
> > > >> decoding could repeat an error until logical decoding completes
> > > >> successfully and its shutdown callback is called. Also, it might be a
> > > >> good idea in general to ensure cleaning up the hash table after use.
> > > >
> > > > Agreed, let's backpatch to PG13. Should we also add a test case in the
> > > > master branch, given that this issue has been around for a while?
> > > >
> > >
> > > I'm wondering if it is a good idea because the bug doesn't manifest in v13 and
> > > v14. At least the v13 has its final minor version in less than a month and EOL.
> > > I would have caution when applying fixes to the latest minor version of a
> > > stable branch; there won't be a chance to fix the fix in the next minor
> > > release. Furthermore, in these back branches, the patch doesn't fix a known
> > > issue. I wouldn't bother with these back branches. For v14, if, in a couple of
> > > months, we have some reports that justify the backpatch, fine.
> >
> > Agreed. I'm hesitant with patching to v13 and v14. We've never got
> > such a bug report yet and the next minior version of v13 would be the
> > final release. I'll add some comments in the commit message.
> >
>
> And now pushed (from master to v15).

Thanks for committing the changes. I monitored the build farm, and the
runs completed successfully. I've also closed the Cf entry at [1].
[1] - https://commitfest.postgresql.org/patch/5903/

Regards,
Vignesh

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2025-10-11 14:48:44 Re: memory leak in dbase_redo()
Previous Message vignesh C 2025-10-11 14:12:29 Re: Logical Replication of sequences