From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Subject: Re: Confused coding in PLy_traceback()
In-reply-to: <2954090.1748723636@sss.pgh.pa.us>
References: <2954090.1748723636@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Sat, 31 May 2025 16:33:56 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3395262.1748804737.1@sss.pgh.pa.us>
Date: Sun, 01 Jun 2025 15:05:37 -0400
Message-ID: <3395263.1748804737@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3395263.1748804737%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> So I propose the attached.  For ease of review, I've not re-indented
> the code that needs to move inside PG_TRY blocks.  Also, I dropped the
> logic about pfree'ing the string buffers in PLy_elog_impl's PG_FINALLY
> block: that doesn't seem necessary, and continuing to do it would
> require making those things volatile which is notationally messy.

Pushed.  After sleeping on it I decided that removing the pfree's
would be a poor tradeoff, as it's not clear how long those allocations
might survive otherwise.  The extra "volatile" markers for "xmsg"
and "tbmsg" aren't that big a deal.  Trying to mark "emsg" as volatile
would be problematic because none of the StringInfo routines are set
up to allow that, but it shouldn't be a problem because that struct
will surely be on the stack.

			regards, tom lane