Re: Invalid pointer access in logical decoding after error

Masahiko Sawada <sawada.mshk@gmail.com>

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

To: Euler Taveira <euler@eulerto.com>

Cc: vignesh C <vignesh21@gmail.com>, "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2025-10-09T17:07:22Z

Lists: pgsql-hackers

Commits

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

Fix access-to-already-freed-memory issue in pgoutput.
- c40761759fe4 15.15 landed
- b07682bce301 16.11 landed
- a61592253e57 17.7 landed
- 32b95fc71b58 18.1 landed
- b46efe90482b 19 (unreleased) landed
Fix memory leak in pgoutput with publication list cache
- bbe68c13abe0 17.3 cited

On Thu, Oct 9, 2025 at 8:23 AM Euler Taveira <euler@eulerto.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.mshk@gmail.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.

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com