Re: Invalid pointer access in logical decoding after error

From: "Euler Taveira" <euler(at)eulerto(dot)com>
To: "Masahiko Sawada" <sawada(dot)mshk(at)gmail(dot)com>, "vignesh C" <vignesh21(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-07 01:54:33
Message-ID: 8da2a299-e1a3-4d17-9758-8a183f47d321@app.fastmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
lrbug1.sql application/sql 661 bytes
lrbug2.sql application/sql 765 bytes

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2025-10-07 02:00:18 RE: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE
Previous Message Tom Lane 2025-10-07 01:48:35 Re: Teaching planner to short-circuit empty UNION/EXCEPT/INTERSECT inputs