From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
cc: Alexander Lakhin <exclusion@gmail.com>, zuming.jiang@inf.ethz.ch,
        pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17995: Segmentation fault caused by UPDATE statement
In-reply-to: <ZJkSW1F78yDV2bjl@paquier.xyz>
References: <17995-9f20ff3e6389db4c@postgresql.org>
 <285547.1687636319@sss.pgh.pa.us>
 <68148dac-a574-f421-2905-51ebde2fe000@gmail.com>
 <ZJkSW1F78yDV2bjl@paquier.xyz>
Comments: In-reply-to Michael Paquier <michael@paquier.xyz>
	message dated "Mon, 26 Jun 2023 13:21:47 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <636982.1687753628.1@sss.pgh.pa.us>
Date: Mon, 26 Jun 2023 00:27:08 -0400
Message-ID: <636983.1687753628@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/636983.1687753628%40sss.pgh.pa.us>
Precedence: bulk

Michael Paquier <michael@paquier.xyz> writes:
> On Sun, Jun 25, 2023 at 06:00:00AM +0300, Alexander Lakhin wrote:
>> BTW, there is a commitfest entry to eliminate a bunch of other stack
>> overflow hazards (may be the fuzzer can find some of them too):
>> https://commitfest.postgresql.org/43/4239/

> Thanks for the pointer, I'll double-check that.  Some of the locations
> of stack depth checks proposed involve performance-sensitive code
> paths, though, like mcxt.c :/

I hadn't looked at the patch yet, but ... mcxt.c?  How is that recursive?
Even if there is some path that recurses through that, wouldn't the
check be better placed in a less-hot part of the loop?

			regards, tom lane