From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amul Sul <sulamul@gmail.com>
Cc: pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Avoid crashing when a JIT-inlined backend function throws an err
Date: Thu, 11 Jul 2024 10:42:15 -0400
Message-ID: <2077809.1720708935@sss.pgh.pa.us> (raw)
In-Reply-To: <CAAJ_b97pUJoxJ_B-ijD87osHZzm2+ZJ=96GdK1--7FLztr+xvg@mail.gmail.com>
References: <E1sMu6Y-003GZV-TB@gemulon.postgresql.org>
<CAAJ_b97pUJoxJ_B-ijD87osHZzm2+ZJ=96GdK1--7FLztr+xvg@mail.gmail.com>
Amul Sul <sulamul@gmail.com> writes:
> On Fri, Jun 28, 2024 at 12:14 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Rather than fixing this by adding pstrdup() overhead to every
>> elog/ereport sequence, let's fix it by copying the risky pointers
>> in CopyErrorData(). That solves it for _SPI_commit/_SPI_rollback
>> because they use that function to preserve the error data across
>> the transaction end/restart sequence; and it seems likely that
>> any other code doing something similar would need to do that too.
> Should we make a similar change to ReThrowError() as well? I'm
> particularly concerned about cases where someone might copy error data
> using CopyErrorData() and then rethrowing that copied edata.
I'd prefer not to propagate this kluge further than we provably
have to. We've already created a memory leak with uncertain
consequences in that FreeErrorData no longer reliably frees
everything in the structure. Adding more copying steps makes
that worse. So without demonstrable gain, I'd rather leave it
alone.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: tgl@sss.pgh.pa.us, sulamul@gmail.com, pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Avoid crashing when a JIT-inlined backend function throws an err
In-Reply-To: <2077809.1720708935@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox