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
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>
Comments: In-reply-to Amul Sul <sulamul@gmail.com>
	message dated "Thu, 11 Jul 2024 16:41:54 +0530"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <2077808.1720708935.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Thu, 11 Jul 2024 10:42:15 -0400
Message-ID: <2077809.1720708935@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2077809.1720708935%40sss.pgh.pa.us>
Precedence: bulk

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