From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Lakhin <exclusion@gmail.com>
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault
In-reply-to: <3140126.1709405398@sss.pgh.pa.us>
References: <18374-ebb8113ce4d02f0d@postgresql.org> <3120721.1709395887@sss.pgh.pa.us> <b1a1eaf3-d5b7-da52-6bb7-c5b3fbe47f3e@gmail.com> <3140126.1709405398@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Sat, 02 Mar 2024 13:49:58 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3148161.1709409519.1@sss.pgh.pa.us>
Date: Sat, 02 Mar 2024 14:58:39 -0500
Message-ID: <3148162.1709409519@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/3148162.1709409519%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> I think what must be happening is that the kernel is refusing
> to expand our stack any more once we've hit the "ulimit -v" limit.
> This is quite nasty, because it breaks all our assumptions about
> having X amount of stack still available once check_stack_depth
> triggers.

I find this in [1]:

  The C language stack growth does an implicit mremap. If you want absolute
  guarantees and run close to the edge you MUST mmap your stack for the 
  largest size you think you will need. For typical stack usage this does
  not matter much but it's a corner case if you really really care

Seems like we need to do some more work at startup to enforce that
we have the amount of stack we think we do, if we're on Linux.

			regards, tom lane

[1] https://www.kernel.org/doc/Documentation/vm/overcommit-accounting