Re: Invalid pointer access in logical decoding after error - Mailing list pgsql-hackers

From Euler Taveira
Subject Re: Invalid pointer access in logical decoding after error
Date
Msg-id 8da2a299-e1a3-4d17-9758-8a183f47d321@app.fastmail.com
Whole thread Raw
In response to Re: Invalid pointer access in logical decoding after error  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
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/
Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Teaching planner to short-circuit empty UNION/EXCEPT/INTERSECT inputs
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE