Message-ID: <916440ee-5c84-abce-e2c8-562dc5775404@gmail.com>
Date: Mon, 26 Jun 2023 08:00:01 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: BUG #17995: Segmentation fault caused by UPDATE statement
Content-Language: en-US
To: Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>
Cc: zuming.jiang@inf.ethz.ch, pgsql-bugs@lists.postgresql.org,
 kyzevan23@mail.ru
References: <17995-9f20ff3e6389db4c@postgresql.org>
 <285547.1687636319@sss.pgh.pa.us>
 <68148dac-a574-f421-2905-51ebde2fe000@gmail.com>
 <ZJkSW1F78yDV2bjl@paquier.xyz> <636983.1687753628@sss.pgh.pa.us>
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <636983.1687753628@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/916440ee-5c84-abce-e2c8-562dc5775404%40gmail.com>
Precedence: bulk

26.06.2023 07:27, Tom Lane wrote:
> 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?

In that thread Egor Chindyaskin showed proofs for stack overflow in all the
functions, that the fixes were proposed for. For example:
#MemoryContextStatsInternal
(n=1000000; printf "BEGIN;"; for ((i=1;i<=$n;i++)); do printf "SAVEPOINT s$i;"; done; printf "SELECT 
pg_log_backend_memory_contexts(pg_backend_pid())") | psql >/dev/null

Though maybe for some of those functions less-hot places could be found to
check the stack.

Best regards,
Alexander