Re: Invalid pointer access in logical decoding after error

From: "Euler Taveira" <euler(at)eulerto(dot)com>
To: "vignesh C" <vignesh21(at)gmail(dot)com>, "Masahiko Sawada" <sawada(dot)mshk(at)gmail(dot)com>
Cc: "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-09 15:22:59
Message-ID: 50f10d6a-a025-454f-9f74-e0ee7efbacf1@app.fastmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
Euler Taveira
EDB https://www.enterprisedb.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-10-09 15:25:35 Re: Fix for compiler warning triggered in WinGetFuncArgInPartition()
Previous Message Tom Lane 2025-10-09 15:22:39 Re: Adding some error context for lock wait failures