public inbox for pgsql-bugs@postgresql.org
help / color / mirror / Atom feedBUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault
11+ messages / 4 participants
[nested] [flat]
* BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault
@ 2024-03-02 06:00 PG Bug reporting form <noreply@postgresql.org>
2024-03-02 16:11 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 11+ messages in thread
From: PG Bug reporting form @ 2024-03-02 06:00 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: exclusion@gmail.com
The following bug has been logged on the website:
Bug reference: 18374
Logged by: Alexander Lakhin
Email address: exclusion@gmail.com
PostgreSQL version: 16.2
Operating system: Ubuntu 22.04
Description:
When a backend with deeply nested memory contexts hits out-of-memory
condition and logs the contexts, it might lead to a segmentation fault
(due to the lack of free memory again). For example:
$ ulimit -Sv 300000; TESTS=infinite_recurse make -s check-tests
(on 64-bit Ubuntu 22.04)
fails:
# +++ regress check in src/test/regress +++
# using temp instance on port 61698 with PID 809399
not ok 1 - infinite_recurse 286 ms
# (test process exited with exit code 2)
with the following stack trace:
Core was generated by `postgres: law regression [local] SELECT
'.
Program terminated with signal SIGSEGV, Segmentation fault.
warning: Section `.reg-xstate/809680' in core file too small.
#0 0x00005643d12ecd50 in dostr (str=str@entry=0x5643d145b137 " ", slen=2,
target=target@entry=0x7ffdafcb6290) at snprintf.c:1378
1378 {
(gdb) bt
#0 0x00005643d12ecd50 in dostr (str=str@entry=0x5643d145b137 " ", slen=2,
target=target@entry=0x7ffdafcb6290) at snprintf.c:1378
#1 0x00005643d12ed54a in dopr (...) at snprintf.c:417
#2 0x00005643d12edec2 in pg_vfprintf (...) at snprintf.c:257
#3 0x00005643d12edfa7 in pg_fprintf (...) at snprintf.c:270
#4 0x00005643d12c086e in MemoryContextStatsPrint (...,
stats_string=stats_string@entry=0x7ffdafcb68c0 "8192 total in 1 blocks; 5072
free (0 chunks); 3120 used",
print_to_stderr=print_to_stderr@entry=true) at mcxt.c:909
#5 0x00005643d12b9604 in AllocSetStats (...) at aset.c:1508
#6 0x00005643d12c0553 in MemoryContextStatsInternal (...) at mcxt.c:770
...
#675 0x00005643d12c05ee in MemoryContextStatsInternal (...) at mcxt.c:786
#676 0x00005643d12c1030 in MemoryContextStatsDetail (...) at mcxt.c:721
#677 0x00005643d12c1111 in MemoryContextStats (...) at mcxt.c:702
#678 0x00005643d12c19d9 in palloc (size=size@entry=16384) at mcxt.c:1243
#679 0x00005643d12d2ed8 in tuplestore_begin_common (eflags=4,
interXact=interXact@entry=false, maxKBytes=4096) at tuplestore.c:281
#680 0x00005643d12d37c9 in tuplestore_begin_heap (...) at tuplestore.c:331
#681 0x00005643d0f72099 in fmgr_sql (...) at functions.c:1142
...
#20980 0x00005643d0f5fd44 in ExecProcNode (...) at
../../../src/include/executor/executor.h:273
#20981 ExecutePlan (...) at execMain.c:1670
#20982 0x00005643d0f5ff07 in standard_ExecutorRun (...) at execMain.c:365
#20983 0x00005643d0f5ffe1 in ExecutorRun (...) at execMain.c:309
#20984 0x00005643d0f701e9 in postquel_getnext (...) at functions.c:895
#20985 0x00005643d0f71ffa in fmgr_sql (...) at functions.c:1196
#20986 0x00005643d0f5a6db in ExecInterpExpr (...) at execExprInterp.c:734
#20987 0x00005643d0f56aec in ExecInterpExprStillValid (...) at
execExprInterp.c:1870
#20988 0x00005643d0f98075 in ExecEvalExprSwitchContext (...) at
../../../src/include/executor/executor.h:355
#20989 ExecProject (...) at ../../../src/include/executor/executor.h:389
#20990 ExecResult (...) at nodeResult.c:136
#20991 0x00005643d0f67781 in ExecProcNodeFirst (...) at execProcnode.c:464
#20992 0x00005643d0f5fd44 in ExecProcNode (...) at execMain.c:1670
#20994 0x00005643d0f5ff07 in standard_ExecutorRun (...) at execMain.c:365
#20995 0x00005643d0f5ffe1 in ExecutorRun (...) at execMain.c:309
#20996 0x00005643d0f701e9 in postquel_getnext (...) at functions.c:895
#20997 0x00005643d0f71ffa in fmgr_sql (fcinfo=0x5643d3614430) at
functions.c:1196
#20998 0x00005643d0f5a6db in ExecInterpExpr (...) at execExprInterp.c:734
#20999 0x00005643d0f56aec in ExecInterpExprStillValid (...) at
execExprInterp.c:1870
#21000 0x00005643d0f98075 in ExecEvalExprSwitchContext (...) at
../../../src/include/executor/executor.h:355
#21001 ExecProject (...) at ../../../src/include/executor/executor.h:389
#21002 ExecResult (...) at nodeResult.c:136
#21003 0x00005643d0f67781 in ExecProcNodeFirst (...) at execProcnode.c:464
#21004 0x00005643d0f5fd44 in ExecProcNode (...) at
../../../src/include/executor/executor.h:273
...
(gdb) p $rsp
$1 = (void *) 0x7ffdafcb6000
(gdb) x $rsp
0x7ffdafcb6000: 0xe92636c0
(gdb) x $rsp - 8
0x7ffdafcb5ff8: Cannot access memory at address 0x7ffdafcb5ff8
postmaster.log contains:
TopMemoryContext: 196064 total in 7 blocks; 45920 free (17 chunks); 150144
used
...
TopPortalContext: 8192 total in 1 blocks; 7656 free (0 chunks); 536 used
PortalContext: 1024 total in 1 blocks; 592 free (0 chunks); 432 used:
<unnamed>
ExecutorState: 8192 total in 1 blocks; 4032 free (0 chunks); 4160
used
SQL function: 32832 total in 3 blocks; 5136 free (1 chunks); 27696
used: infinite_recurse
ExecutorState: 8192 total in 1 blocks; 5072 free (0 chunks); 3120
used
SQL function: 32832 total in 3 blocks; 5136 free (1 chunks);
27696 used: infinite_recurse
...
(Initially observed with the natural restrictions on 32-bit OS.)
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault
2024-03-02 06:00 BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault PG Bug reporting form <noreply@postgresql.org>
@ 2024-03-02 16:11 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-03-02 17:00 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Alexander Lakhin <exclusion@gmail.com>
0 siblings, 1 reply; 11+ messages in thread
From: Tom Lane @ 2024-03-02 16:11 UTC (permalink / raw)
To: exclusion@gmail.com; +Cc: pgsql-bugs@lists.postgresql.org
PG Bug reporting form <noreply@postgresql.org> writes:
> When a backend with deeply nested memory contexts hits out-of-memory
> condition and logs the contexts, it might lead to a segmentation fault
> (due to the lack of free memory again).
Hmph. That's not an out-of-memory crash, that's a stack-too-deep
crash.
Seems like we ought to do one or both of these:
1. Put a CHECK_STACK_DEPTH() call in MemoryContextStatsInternal.
2. Teach MemoryContextStatsInternal to refuse to recurse more
than N levels, for N perhaps around 100.
Neither of these are very attractive though, as they'd obscure
the OOM situation that we're trying to help debug.
It strikes me that we don't actually need recursion in order to
traverse the context tree: since the nodes have parent pointers,
it'd be possible to visit them all using only iteration. The
recursion seems necessary though to manage the child summarization
logic as we have it (in particular, we must have a local_totals
per level to produce summarization like this). Maybe we could
modify solution #2 into
2a. Once we get more than say 100 levels deep, summarize everything
below that in a single line, obtained in an iterative rather than
recursive traversal.
I wonder whether MemoryContextDelete and other cleanup methods
also need to be rewritten to avoid recursion. In the infinite_recurse
test case I think we escape trouble because we longjmp out of most
of the stack before we try to clean up --- but you could probably
devise a test case that tries to do a subtransaction abort at a
deep call level, and then maybe kaboom?
regards, tom lane
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault
2024-03-02 06:00 BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault PG Bug reporting form <noreply@postgresql.org>
2024-03-02 16:11 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-03-02 17:00 ` Alexander Lakhin <exclusion@gmail.com>
2024-03-02 18:49 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 11+ messages in thread
From: Alexander Lakhin @ 2024-03-02 17:00 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-bugs@lists.postgresql.org
Hello Tom,
02.03.2024 19:11, Tom Lane wrote:
> PG Bug reporting form <noreply@postgresql.org> writes:
>> When a backend with deeply nested memory contexts hits out-of-memory
>> condition and logs the contexts, it might lead to a segmentation fault
>> (due to the lack of free memory again).
> Hmph. That's not an out-of-memory crash, that's a stack-too-deep
> crash.
I tried to decrease the limit and still got the failure (with the much
shorter stack):
ulimit -Sv 200000; TESTS=infinite_recurse make -s check-tests
(gdb) p $rsp
$1 = (void *) 0x7ffcc83d4ff0
(gdb) frame 13269
#13269 0x000056289bc2685a in main (argc=8, argv=0x56289d3b4930) at main.c:198
198 PostmasterMain(argc, argv);
(gdb) p $rsp
$2 = (void *) 0x7ffcc84834d0
(gdb) p $rsp - 0x7ffcc83d4ff0
$3 = (void *) 0xae4e0
(Far less than ulimit -s == 8 MB.)
It made me think that it's not a stack overflow issue, but may be I miss
something.
> Seems like we ought to do one or both of these:
>
> 1. Put a CHECK_STACK_DEPTH() call in MemoryContextStatsInternal.
>
> 2. Teach MemoryContextStatsInternal to refuse to recurse more
> than N levels, for N perhaps around 100.
>
> Neither of these are very attractive though, as they'd obscure
> the OOM situation that we're trying to help debug.
>
> It strikes me that we don't actually need recursion in order to
> traverse the context tree: since the nodes have parent pointers,
> it'd be possible to visit them all using only iteration. The
> recursion seems necessary though to manage the child summarization
> logic as we have it (in particular, we must have a local_totals
> per level to produce summarization like this). Maybe we could
> modify solution #2 into
>
> 2a. Once we get more than say 100 levels deep, summarize everything
> below that in a single line, obtained in an iterative rather than
> recursive traversal.
>
> I wonder whether MemoryContextDelete and other cleanup methods
> also need to be rewritten to avoid recursion. In the infinite_recurse
> test case I think we escape trouble because we longjmp out of most
> of the stack before we try to clean up --- but you could probably
> devise a test case that tries to do a subtransaction abort at a
> deep call level, and then maybe kaboom?
Exploiting and protecting MemoryContextStatsInternal() were discussed
before:
https://www.postgresql.org/message-id/flat/1661334672.728714027%40f473.i.mail.ru
(It looks like the function got no stack-overflow protection at the end.)
But I'm still not sure that we deal here with the same issue.
Best regards,
Alexander
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault
2024-03-02 06:00 BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault PG Bug reporting form <noreply@postgresql.org>
2024-03-02 16:11 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
2024-03-02 17:00 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Alexander Lakhin <exclusion@gmail.com>
@ 2024-03-02 18:49 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-03-02 19:58 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 11+ messages in thread
From: Tom Lane @ 2024-03-02 18:49 UTC (permalink / raw)
To: Alexander Lakhin <exclusion@gmail.com>; +Cc: pgsql-bugs@lists.postgresql.org
Alexander Lakhin <exclusion@gmail.com> writes:
> 02.03.2024 19:11, Tom Lane wrote:
>> Hmph. That's not an out-of-memory crash, that's a stack-too-deep
>> crash.
> (gdb) p $rsp
> $1 = (void *) 0x7ffcc83d4ff0
> (gdb) frame 13269
> #13269 0x000056289bc2685a in main (argc=8, argv=0x56289d3b4930) at main.c:198
> 198 PostmasterMain(argc, argv);
> (gdb) p $rsp
> $2 = (void *) 0x7ffcc84834d0
> (gdb) p $rsp - 0x7ffcc83d4ff0
> $3 = (void *) 0xae4e0
> (Far less than ulimit -s == 8 MB.)
Yeah, I'm seeing something similar, also with ulimit -s = 8192 kbytes:
(gdb) i reg
...
rbp 0xb0a324 0xb0a324
rsp 0x7ffd07ce4fd0 0x7ffd07ce4fd0
...
(gdb) x/64 0x7ffd07ce4fd0
0x7ffd07ce4fd0: Cannot access memory at address 0x7ffd07ce4fd0
So it's definitely out-of-stack, yet
(gdb) p stack_base_ptr
$3 = 0x7ffd07dbf570 "\b"
(gdb) p 0x7ffd07dbf570 - 0x7ffd07ce4fd0
$4 = 894368
I'd have expected a diff in the vicinity of 8MB, but it isn't.
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 tried inserting check_stack_depth() into MemoryContextStatsInternal,
and *that did not stop the crash*, confirming that we don't think
we're anywhere near the stack limit. Ugh.
regards, tom lane
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault
2024-03-02 06:00 BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault PG Bug reporting form <noreply@postgresql.org>
2024-03-02 16:11 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
2024-03-02 17:00 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Alexander Lakhin <exclusion@gmail.com>
2024-03-02 18:49 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-03-02 19:58 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-03-03 21:39 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 11+ messages in thread
From: Tom Lane @ 2024-03-02 19:58 UTC (permalink / raw)
To: Alexander Lakhin <exclusion@gmail.com>; +Cc: pgsql-bugs@lists.postgresql.org
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
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault
2024-03-02 06:00 BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault PG Bug reporting form <noreply@postgresql.org>
2024-03-02 16:11 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
2024-03-02 17:00 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Alexander Lakhin <exclusion@gmail.com>
2024-03-02 18:49 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
2024-03-02 19:58 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-03-03 21:39 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-03-04 15:00 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Alexander Lakhin <exclusion@gmail.com>
2024-03-06 20:24 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Alexander Korotkov <aekorotkov@gmail.com>
2026-05-16 19:00 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Alexander Lakhin <exclusion@gmail.com>
0 siblings, 3 replies; 11+ messages in thread
From: Tom Lane @ 2024-03-03 21:39 UTC (permalink / raw)
To: Alexander Lakhin <exclusion@gmail.com>; +Cc: pgsql-bugs@lists.postgresql.org
I wrote:
> 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.
After thinking about that some more, I'm really quite unenthused about
trying to remap the stack for ourselves. It'd be both platform- and
architecture-dependent, and I'm afraid it'd introduce as many failure
modes as it removes. (Notably, I'm not sure we could guarantee
there's a guard page below the stack.) Since we've not seen reports
of this failure from the wild, I doubt it's worth the trouble.
I do think it's probably worth reducing MemoryContextDelete's stack
usage to O(1), just to ensure we can't get into stack trouble during
transaction abort. That's not hard at all, as attached.
I tried to make MemoryContextResetChildren work similarly, but that
doesn't work because if we're not removing child contexts then we
need extra state to tell which ones we've done already. For the
same reason my idea for bounding the stack space needed by
MemoryContextStats doesn't seem to work. We could possibly make it
work if we were willing to add a temporary-use pointer field to all
MemoryContext headers, but I'm unconvinced that'd be a good tradeoff.
regards, tom lane
Attachments:
[text/x-diff] memory-context-delete-with-fixed-stack-space.patch (1.4K, 2-memory-context-delete-with-fixed-stack-space.patch)
download | inline diff:
diff --git a/src/backend/utils/mmgr/mcxt.c b/src/backend/utils/mmgr/mcxt.c
index 41f2390fb8..7cc220bca0 100644
--- a/src/backend/utils/mmgr/mcxt.c
+++ b/src/backend/utils/mmgr/mcxt.c
@@ -447,14 +447,37 @@ MemoryContextDelete(MemoryContext context)
void
MemoryContextDeleteChildren(MemoryContext context)
{
+ MemoryContext cur,
+ next;
+
Assert(MemoryContextIsValid(context));
/*
- * MemoryContextDelete will delink the child from me, so just iterate as
- * long as there is a child.
+ * We iterate rather than recursing, so that cleaning up a deep nest of
+ * contexts doesn't require unbounded stack space. (This avoids possible
+ * failure during transaction cleanup, which would be bad.) This works
+ * because by the time we traverse back up to a parent context, it will
+ * have no remaining children and will be seen as deletable.
*/
- while (context->firstchild != NULL)
- MemoryContextDelete(context->firstchild);
+ cur = context->firstchild;
+ while (cur != NULL)
+ {
+ /* Descend until we find a childless context */
+ if (cur->firstchild != NULL)
+ {
+ cur = cur->firstchild;
+ continue;
+ }
+ /* We can delete cur, but first remember the next deletion target */
+ if (cur->nextchild != NULL)
+ next = cur->nextchild;
+ else if (cur->parent != context)
+ next = cur->parent;
+ else
+ next = NULL;
+ MemoryContextDelete(cur);
+ cur = next;
+ }
}
/*
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault
2024-03-02 06:00 BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault PG Bug reporting form <noreply@postgresql.org>
2024-03-02 16:11 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
2024-03-02 17:00 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Alexander Lakhin <exclusion@gmail.com>
2024-03-02 18:49 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
2024-03-02 19:58 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
2024-03-03 21:39 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-03-04 15:00 ` Alexander Lakhin <exclusion@gmail.com>
2024-03-06 16:00 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Alexander Lakhin <exclusion@gmail.com>
2 siblings, 1 reply; 11+ messages in thread
From: Alexander Lakhin @ 2024-03-04 15:00 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-bugs@lists.postgresql.org
Hello Tom,
04.03.2024 00:39, Tom Lane wrote:
> I wrote:
>> 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.
> After thinking about that some more, I'm really quite unenthused about
> trying to remap the stack for ourselves. It'd be both platform- and
> architecture-dependent, and I'm afraid it'd introduce as many failure
> modes as it removes. (Notably, I'm not sure we could guarantee
> there's a guard page below the stack.) Since we've not seen reports
> of this failure from the wild, I doubt it's worth the trouble.
I have perhaps a naive idea, but it apparently eliminates the segmentation
fault for the given test case. (Please look at a quick draft attached.)
Though maybe the issue can really wait for complaints from outside or for
a simpler/cheaper solution, integrated with the existing (or future)
stack-overflow protection.
> I do think it's probably worth reducing MemoryContextDelete's stack
> usage to O(1), just to ensure we can't get into stack trouble during
> transaction abort. That's not hard at all, as attached.
Yeah, Heikki proposed something similar as part of
0003-Avoid-recursion-in-MemoryContext-functions.patch there:
https://www.postgresql.org/message-id/6b48c746-9704-46dc-b9be-01fe4137c824%40iki.fi
> I tried to make MemoryContextResetChildren work similarly, but that
> doesn't work because if we're not removing child contexts then we
> need extra state to tell which ones we've done already. For the
> same reason my idea for bounding the stack space needed by
> MemoryContextStats doesn't seem to work. We could possibly make it
> work if we were willing to add a temporary-use pointer field to all
> MemoryContext headers, but I'm unconvinced that'd be a good tradeoff.
Best regards,
Alexander
Attachments:
[text/x-patch] acquire-memory-for-stack.patch (656B, 2-acquire-memory-for-stack.patch)
download | inline diff:
diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
index 59ab812d2e..bb9d309f4e 100644
--- a/src/backend/tcop/postgres.c
+++ b/src/backend/tcop/postgres.c
@@ -3464,6 +3464,14 @@ ProcessInterrupts(void)
HandleParallelApplyMessages();
}
+void prepare_stack(int n)
+{
+ char buffer[1024 * 1024];
+ memset(buffer, 0, sizeof(buffer));
+ if (n > 0)
+ prepare_stack(n - 1);
+}
+
/*
* set_stack_base: set up reference point for stack depth checking
*
@@ -3490,6 +3498,7 @@ set_stack_base(void)
stack_base_ptr = &stack_base;
#endif
+ prepare_stack((max_stack_depth_bytes + STACK_DEPTH_SLOP) / (1024 * 1024));
return old;
}
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault
2024-03-02 06:00 BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault PG Bug reporting form <noreply@postgresql.org>
2024-03-02 16:11 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
2024-03-02 17:00 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Alexander Lakhin <exclusion@gmail.com>
2024-03-02 18:49 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
2024-03-02 19:58 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
2024-03-03 21:39 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
2024-03-04 15:00 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Alexander Lakhin <exclusion@gmail.com>
@ 2024-03-06 16:00 ` Alexander Lakhin <exclusion@gmail.com>
0 siblings, 0 replies; 11+ messages in thread
From: Alexander Lakhin @ 2024-03-06 16:00 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-bugs@lists.postgresql.org
04.03.2024 18:00, Alexander Lakhin wrote:
>
> 04.03.2024 00:39, Tom Lane wrote:
>>
>>> 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.
>> After thinking about that some more, I'm really quite unenthused about
>> trying to remap the stack for ourselves. It'd be both platform- and
>> architecture-dependent, and I'm afraid it'd introduce as many failure
>> modes as it removes. (Notably, I'm not sure we could guarantee
>> there's a guard page below the stack.) Since we've not seen reports
>> of this failure from the wild, I doubt it's worth the trouble.
>
I've discovered that the out-of-stack segfault can be reached without
hitting an ordinary OOM condition at all.
Please look at the demo script that finds -v value for the given sql
recursion (the predefined range works for a server built with
CPPFLAGS="-Og" ./configure --enable-cassert --enable-debug,
using gcc 11.3 on 64-bit Ubuntu):
for v in `seq 240000 100 260000`; do
echo "limit -v: $v"
ulimit -Sv $v
rm server.log
pg_ctl -l server.log start
dropdb test
createdb test
cat << 'EOF' | psql test >psql.log 2>&1
create function explainer(text) returns setof text
language plpgsql as
$$
declare
ln text;
begin
for ln in execute format('explain analyze %s', $1)
loop
return next ln;
end loop;
end;
$$;
prepare stmt as select explainer('execute stmt');
select explainer('execute stmt');
EOF
pg_ctl stop || break
grep 'was terminated by signal 11' server.log && break;
done
This script fails for me as follows:
limit -v: 241100
waiting for server to start.... done
server started
waiting for server to shut down.......... done
server stopped
2024-03-06 14:45:26.882 UTC [38567] LOG: server process (PID 38634) was terminated by signal 11: Segmentation fault
(with no out-of-memory errors in the server.log)
Core was generated by `postgres: law test [local] SELECT '.
Program terminated with signal SIGSEGV, Segmentation fault.
warning: Section `.reg-xstate/38634' in core file too small.
#0 0x0000563ea8af7d60 in base_yyparse (yyscanner=yyscanner@entry=0x563eacbeec38) at gram.c:29020
bt
29020 {
(gdb) bt
#0 0x0000563ea8af7d60 in base_yyparse (yyscanner=yyscanner@entry=0x563eacbeec38) at gram.c:29020
#1 0x0000563ea8b37d4e in raw_parser (str=str@entry=0x563eacbf2c58 "explain analyze execute stmt", mode=<optimized out>)
at parser.c:77
#2 0x0000563ea8c19217 in _SPI_prepare_plan (src=src@entry=0x563eacbf2c58 "explain analyze execute stmt",
plan=plan@entry=0x7fffb16323b0) at spi.c:2235
#3 0x0000563ea8c1c5f5 in SPI_cursor_parse_open (name=name@entry=0x0, src=src@entry=0x563eacbf2c58 "explain analyze
execute stmt", options=options@entry=0x7fffb1632450) at spi.c:1554
...
#11389 0x0000563ea8d8bbf2 in exec_simple_query (query_string=query_string@entry=0x563eaa5c6328 "select
explainer('execute stmt');") at postgres.c:1273
#11390 0x0000563ea8d8daae in PostgresMain (dbname=<optimized out>, username=<optimized out>) at postgres.c:4675
#11391 0x0000563ea8cf9c5d in BackendRun (port=port@entry=0x563eaa5f38c0) at postmaster.c:4475
#11392 0x0000563ea8cfcc10 in BackendStartup (port=port@entry=0x563eaa5f38c0) at postmaster.c:4151
#11393 0x0000563ea8cfcdae in ServerLoop () at postmaster.c:1769
#11394 0x0000563ea8cfe120 in PostmasterMain (argc=argc@entry=3, argv=argv@entry=0x563eaa5c1760) at postmaster.c:1468
#11395 0x0000563ea8c3148d in main (argc=3, argv=0x563eaa5c1760) at main.c:197
(gdb) i reg
rbp 0x563eacbeec38 0x563eacbeec38
rsp 0x7fffb16316b0 0x7fffb16316b0
(gdb) x/4 0x7fffb1631ff0
0x7fffb1631ff0: Cannot access memory at address 0x7fffb1631ff0
(gdb) x/4 0x7fffb1632000
0x7fffb1632000: 0 0 0 0
(gdb) p stack_base_ptr
$1 = 0x7fffb17ac660 "\001"
(gdb) p stack_base_ptr - $rsp
$2 = 1552304
So it looks like a very specific corner stack-overflow case.
Best regards,
Alexander
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault
2024-03-02 06:00 BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault PG Bug reporting form <noreply@postgresql.org>
2024-03-02 16:11 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
2024-03-02 17:00 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Alexander Lakhin <exclusion@gmail.com>
2024-03-02 18:49 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
2024-03-02 19:58 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
2024-03-03 21:39 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-03-06 20:24 ` Alexander Korotkov <aekorotkov@gmail.com>
2024-03-06 21:21 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 1 reply; 11+ messages in thread
From: Alexander Korotkov @ 2024-03-06 20:24 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Alexander Lakhin <exclusion@gmail.com>; pgsql-bugs@lists.postgresql.org
On Sun, Mar 3, 2024 at 11:39 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I do think it's probably worth reducing MemoryContextDelete's stack
> usage to O(1), just to ensure we can't get into stack trouble during
> transaction abort. That's not hard at all, as attached.
>
> I tried to make MemoryContextResetChildren work similarly, but that
> doesn't work because if we're not removing child contexts then we
> need extra state to tell which ones we've done already. For the
> same reason my idea for bounding the stack space needed by
> MemoryContextStats doesn't seem to work. We could possibly make it
> work if we were willing to add a temporary-use pointer field to all
> MemoryContext headers, but I'm unconvinced that'd be a good tradeoff.
For removing recursion from memory context processing, please check
the patch by Heikki [1], and my slightly revised version [2].
Links.
1. https://www.postgresql.org/message-id/6b48c746-9704-46dc-b9be-01fe4137c824%40iki.fi
2. https://www.postgresql.org/message-id/CAPpHfdtQVzkKgrxqKZE9yESnu7cAATVQbGktVOSXPNWG7GOkhA%40mail.gma...
------
Regards,
Alexander Korotkov
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault
2024-03-02 06:00 BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault PG Bug reporting form <noreply@postgresql.org>
2024-03-02 16:11 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
2024-03-02 17:00 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Alexander Lakhin <exclusion@gmail.com>
2024-03-02 18:49 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
2024-03-02 19:58 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
2024-03-03 21:39 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
2024-03-06 20:24 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Alexander Korotkov <aekorotkov@gmail.com>
@ 2024-03-06 21:21 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 11+ messages in thread
From: Tom Lane @ 2024-03-06 21:21 UTC (permalink / raw)
To: Alexander Korotkov <aekorotkov@gmail.com>; +Cc: Alexander Lakhin <exclusion@gmail.com>; pgsql-bugs@lists.postgresql.org
Alexander Korotkov <aekorotkov@gmail.com> writes:
> For removing recursion from memory context processing, please check
> the patch by Heikki [1], and my slightly revised version [2].
> Links.
> 1. https://www.postgresql.org/message-id/6b48c746-9704-46dc-b9be-01fe4137c824%40iki.fi
> 2. https://www.postgresql.org/message-id/CAPpHfdtQVzkKgrxqKZE9yESnu7cAATVQbGktVOSXPNWG7GOkhA%40mail.gma...
I'd forgotten about that thread. I'll comment there, thanks!
The issue Alexander has identified about the kernel possibly not
giving us as much stack as promised should stay in this thread,
but we can discuss the idea of de-recursing mcxt.c over there.
regards, tom lane
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault
2024-03-02 06:00 BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault PG Bug reporting form <noreply@postgresql.org>
2024-03-02 16:11 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
2024-03-02 17:00 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Alexander Lakhin <exclusion@gmail.com>
2024-03-02 18:49 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
2024-03-02 19:58 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
2024-03-03 21:39 ` Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
@ 2026-05-16 19:00 ` Alexander Lakhin <exclusion@gmail.com>
2 siblings, 0 replies; 11+ messages in thread
From: Alexander Lakhin @ 2026-05-16 19:00 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-bugs@lists.postgresql.org; Heikki Linnakangas <hlinnaka@iki.fi>
Hello Tom,
03.03.2024 23:39, Tom Lane wrote:
> I wrote:
>> 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.
> After thinking about that some more, I'm really quite unenthused about
> trying to remap the stack for ourselves. It'd be both platform- and
> architecture-dependent, and I'm afraid it'd introduce as many failure
> modes as it removes. (Notably, I'm not sure we could guarantee
> there's a guard page below the stack.) Since we've not seen reports
> of this failure from the wild, I doubt it's worth the trouble.
I'm not too excited either, but I observed such SIGSEGVs in a
memory-restricted cloud (neon) environment (perhaps it could be considered
the wild), and what looks bad to me is that there is no protection from it
at all. That is, if you can get an out-of-memory error in some environment,
you can also bring the whole server down with the segfault, occasionally or
intentionally.
I researched the subject and found the only way to prevent this -- to
allocate the stack memory (up to max_stack_depth) on postmaster child's
start.
Please look at a test, which triggers the server crash, and a possible
protection.
When running this test on Linux, I'm getting:
PROVE_TESTS="t/099*" make -s check -C src/test/modules/test_misc/
# Testing ulimit -Sv 280000
# out of memory
# Testing ulimit -Sv 1140000
# stack depth limit exceeded
...
# Boundary between 'out of memory' and 'stack depth limit exceeded' found: 283779
...
# Testing ulimit -Sv 275587
# psql:<stdin>:17: server closed the connection unexpectedly
# This probably means the server terminated abnormally
# before or while processing the request.
2026-05-16 20:33:30.724 EEST postmaster[4101481] LOG: client backend (PID 4101496) was terminated by signal 11:
Segmentation fault
2026-05-16 20:33:30.724 EEST postmaster[4101481] DETAIL: Failed process was running: select explainer('execute stmt');
While with echo "preallocate_stack=on" >/tmp/temp.config;
TEMP_CONFIG=/tmp/temp.config PROVE_TESTS="t/099*" make -s check -C src/test/modules/test_misc/
survives the test.
ulimit -Sv is easy to use for the test, but in the wild the restriction
would be rather on the total amount of memory for all (postgres) processes,
so there could be more interesting scenarios...
Catching sigsegv in allocate_stack() is needed to handle correctly the
even worse situation, when there is not enough memory to preallocate stack
even on a process start.
The test and the fix work for me on Linux and FreeBSD.
Yes, this protection has it's price (max_stack_depth * num processes), but
perhaps one who wants to avoid server crashes should have the choice.
Thanks to Heikki for help with making the solution robust.
Best regards,
Alexander
Attachments:
[application/x-perl] 099_stack_overflow.pl (2.3K, 2-099_stack_overflow.pl)
download
[text/x-patch] prevent-segfaults-under-memory-pressure.patch (6.3K, 3-prevent-segfaults-under-memory-pressure.patch)
download | inline diff:
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index 90c7c4528e8..46517c6b092 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -256,6 +256,7 @@ bool remove_temp_files_after_crash = true;
*/
bool send_abort_for_crash = false;
bool send_abort_for_kill = false;
+bool preallocate_stack = false;
/* special child processes; NULL when not running */
static PMChild *StartupPMChild = NULL,
diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
index dbef734a93f..21775456c35 100644
--- a/src/backend/tcop/postgres.c
+++ b/src/backend/tcop/postgres.c
@@ -3619,6 +3619,106 @@ ProcessInterrupts(void)
ProcessRepackMessages();
}
+#ifndef WIN32
+/*
+ * occupy_stack - recursively touch stack pages to force physical allocation
+ *
+ * Each frame allocates 256kB (half of STACK_DEPTH_SLOP). Recursion stops
+ * when stack_is_too_deep() fires.
+ *
+ * Returns the number of frames successfully allocated.
+ */
+static pg_noinline int
+occupy_stack(void)
+{
+ /* Occupy half of STACK_DEPTH_SLOP at once */
+ volatile char stack_data[256 * 1024];
+ volatile char *p = stack_data;
+
+ /* Touch each page to force kernel to back it with physical memory */
+ for (long i = 0; i < sizeof(stack_data); i += 4096)
+ p[i] = 0;
+
+ if (!stack_is_too_deep())
+ return occupy_stack() + 1;
+ return 0;
+}
+
+static sigjmp_buf alt_sigsegv_jump;
+
+/* SIGSEGV handler for allocate_stack() */
+#if defined(USE_SIGACTION) && defined(USE_SIGINFO)
+static void
+alt_sigsegv_handler(int postgres_signal_arg, siginfo_t *info, void *context)
+#else /* no USE_SIGINFO */
+static void
+alt_sigsegv_handler(int postgres_signal_arg)
+#endif
+{
+ siglongjmp(alt_sigsegv_jump, 1);
+}
+#endif
+
+/*
+ * allocate_stack - acquire stack pages to prevent SIGSEGV under memory pressure
+ *
+ * When the system is under memory pressure (e.g., cgroup limits), the kernel
+ * may fail to extend the stack on demand, killing the backend with SIGSEGV
+ * before check_stack_depth() can intervene. This function proactively acquires
+ * physical pages of stack up to max_stack_depth via occupy_stack(), while it
+ * can still handle failures gracefully, using a temporary SIGSEGV handler on
+ * an alternate signal stack.
+ *
+ * Returns the number of frames successfully allocated (0 on Windows).
+ */
+int
+allocate_stack(void)
+{
+ int result = 0;
+
+#ifndef WIN32
+ struct sigaction act, oldact;
+ stack_t ss, old_ss;
+
+ ss.ss_sp = palloc(SIGSTKSZ);
+ ss.ss_size = SIGSTKSZ;
+ ss.ss_flags = 0;
+ if (sigaltstack(&ss, &old_ss) == -1)
+ elog(FATAL, "sigaltstack failed: %m");
+
+ act.sa_flags = SA_ONSTACK;
+ act.sa_handler = alt_sigsegv_handler;
+ sigemptyset(&act.sa_mask);
+ if (sigaction(SIGSEGV, &act, &oldact) == -1)
+ elog(FATAL, "sigaction failed: %m");
+
+ /*
+ * Use sigsetjmp to intercept SIGSEGV that can happen even at the process
+ * start, and in this case occupy_stack() can't handle it.
+ *
+ * Terminating the process with FATAL is the only way to avoid
+ * segfaults later.
+ */
+ if (sigsetjmp(alt_sigsegv_jump, 1) == 0)
+ {
+ result = occupy_stack();
+ }
+ else
+ {
+ /* We got the SIGSEGV trap */
+ elog(FATAL, "could not allocate stack");
+ }
+
+ if (sigaltstack(&old_ss, NULL) == -1)
+ elog(FATAL, "sigaltstack restore failed: %m");
+ if (sigaction(SIGSEGV, &oldact, NULL) == -1)
+ elog(FATAL, "sigaction failed: %m");
+ pfree(ss.ss_sp);
+#endif
+
+ return result;
+}
+
/*
* GUC check_hook for client_connection_check_interval
*/
diff --git a/src/backend/utils/init/miscinit.c b/src/backend/utils/init/miscinit.c
index 7ffc808073a..a0dd7c6f901 100644
--- a/src/backend/utils/init/miscinit.c
+++ b/src/backend/utils/init/miscinit.c
@@ -107,6 +107,9 @@ InitPostmasterChild(void)
pgwin32_signal_initialize();
#endif
+ if (preallocate_stack)
+ (void) allocate_stack();
+
InitProcessGlobals();
/*
diff --git a/src/backend/utils/misc/guc_parameters.dat b/src/backend/utils/misc/guc_parameters.dat
index afaa058b046..b2d5642f572 100644
--- a/src/backend/utils/misc/guc_parameters.dat
+++ b/src/backend/utils/misc/guc_parameters.dat
@@ -2390,6 +2390,12 @@
max => '60',
},
+{ name => 'preallocate_stack', type => 'bool', context => 'PGC_POSTMASTER', group => 'RESOURCES_MEM',
+ short_desc => 'Preallocate stack on subprocess start.',
+ variable => 'preallocate_stack',
+ boot_val => 'false',
+},
+
{ name => 'primary_conninfo', type => 'string', context => 'PGC_SIGHUP', group => 'REPLICATION_STANDBY',
short_desc => 'Sets the connection string to be used to connect to the sending server.',
flags => 'GUC_SUPERUSER_ONLY',
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index ac38cddaaf9..0c112f51684 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -150,6 +150,7 @@
#autovacuum_work_mem = -1 # min 64kB, or -1 to use maintenance_work_mem
#logical_decoding_work_mem = 64MB # min 64kB
#max_stack_depth = 2MB # min 100kB
+#preallocate_stack = off # allocate max_stack_depth on subprocess start
#shared_memory_type = mmap # the default is the first option
# supported by the operating system:
# mmap
diff --git a/src/include/miscadmin.h b/src/include/miscadmin.h
index 8ccdf61246b..b0efa042ec5 100644
--- a/src/include/miscadmin.h
+++ b/src/include/miscadmin.h
@@ -306,6 +306,7 @@ extern void restore_stack_base(pg_stack_base_t base);
extern void check_stack_depth(void);
extern bool stack_is_too_deep(void);
extern ssize_t get_stack_depth_rlimit(void);
+extern int allocate_stack(void);
/* in tcop/utility.c */
extern void PreventCommandIfReadOnly(const char *cmdname);
diff --git a/src/include/postmaster/postmaster.h b/src/include/postmaster/postmaster.h
index 716b4c912b3..7898c021b12 100644
--- a/src/include/postmaster/postmaster.h
+++ b/src/include/postmaster/postmaster.h
@@ -70,6 +70,7 @@ extern PGDLLIMPORT bool restart_after_crash;
extern PGDLLIMPORT bool remove_temp_files_after_crash;
extern PGDLLIMPORT bool send_abort_for_crash;
extern PGDLLIMPORT bool send_abort_for_kill;
+extern PGDLLIMPORT bool preallocate_stack;
#ifdef WIN32
extern PGDLLIMPORT HANDLE PostmasterHandle;
^ permalink raw reply [nested|flat] 11+ messages in thread
end of thread, other threads:[~2026-05-16 19:00 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-03-02 06:00 BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault PG Bug reporting form <noreply@postgresql.org>
2024-03-02 16:11 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-03-02 17:00 ` Alexander Lakhin <exclusion@gmail.com>
2024-03-02 18:49 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-03-02 19:58 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-03-03 21:39 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-03-04 15:00 ` Alexander Lakhin <exclusion@gmail.com>
2024-03-06 16:00 ` Alexander Lakhin <exclusion@gmail.com>
2024-03-06 20:24 ` Alexander Korotkov <aekorotkov@gmail.com>
2024-03-06 21:21 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-05-16 19:00 ` Alexander Lakhin <exclusion@gmail.com>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox