Re: ExecAppendAsyncEventWait() in REL_14_STABLE can corrupt PG_exception_stack

From: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ExecAppendAsyncEventWait() in REL_14_STABLE can corrupt PG_exception_stack
Date: 2024-02-25 09:34:30
Message-ID: CAPmGK17=Asbxv5Bka3SC==yG1q+1MGV9LA6sb_DqLUG7AxbBAQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Sat, Feb 24, 2024 at 10:06 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Fri, Feb 23, 2024 at 01:21:14PM +0300, Alexander Pyhalov wrote:
> > Recent commit 555276f8594087ba15e0d58e38cd2186b9f39f6d introduced final
> > cleanup of node->as_eventset in ExecAppendAsyncEventWait().
> > Unfortunately, now this function can return in the middle of TRY/FINALLY
> > block, without restoring PG_exception_stack.
> >
> > We found this while working on our FDW. Unfortunately, I couldn't reproduce
> > the issue with postgres_fdw, but it seems it is also affected.

I think this would happen when FDWs configure no events; IIRC I think
while the core allows them to do so, postgres_fdw does not do so, so
this would never happen with it. Anyway, thanks for the report and
patch, Alexander!

> Ugh, yes, you are obviously right that the early return is wrong.
> I'll look into fixing that where appropriate.

Thanks for taking care of this, Michael-san! This would result
originally from my fault, so If you don't mind, could you let me do
that?

Best regards,
Etsuro Fujita

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2024-02-25 11:30:37 Re: RFC: Logging plan of the running query
Previous Message Jim Jones 2024-02-25 00:11:42 Re: Patch: Add parse_type Function