Horton

Re: Invalid pointer access in logical decoding after error

Euler Taveira <euler@eulerto.com>

View thread
From: "Euler Taveira" <euler@eulerto.com>
To: "Masahiko Sawada" <sawada.mshk@gmail.com>, "vignesh C" <vignesh21@gmail.com>
Cc: "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>, "PostgreSQL Hackers" <pgsql-hackers@lists.postgresql.org>
Date: 2025-10-07T01:54:33Z
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 →

  1. Fix access-to-already-freed-memory issue in pgoutput.

  2. Fix memory leak in pgoutput with publication list cache

Attachments

On Mon, Oct 6, 2025, at 5:00 PM, Masahiko Sawada wrote:
> I agree with your analysis. It seems there is no convenient way to
> move RelationSyncCache inside PGOutputData. So let's proceed with the
> proposed approach.
>

+1. Shouldn't we add a comment mentioning that it is a possibility?

> I've done some minor changes to your v2 patch and updated the commit
> message. IIUC this patch needs to be backpatched to v15. Please review
> the attached patch.
>

I verified that the bug exists since v15 as reported. Despite of the test case
provided by Vignesh (which I attached a modified version to be used in v15 or
later), I also added another test case that has a similar problem with
generated columns. This 2nd test case only works for v18 (where the feature was
introduced). This patch also fixes this case.

I'm curious about other cases related to RelationSyncCache. Is there any other
cases that this patch doesn't fix?

This patch looks good to me. Do we really need a new function with the same
content as pgoutput_shutdown? I don't like mcallback. It seems 'm' stands for
'memory' but if we want to use crypt names I would suggest 'mcb' (_m_emory
_c_all_b_ack) -- that is also a crypt name but a shorter one. Same pattern is
already used in another place with MemoryContextCallback.


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