Re: Should we add a compiler warning for large stack frames?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>,
Thomas Munro <thomas.munro@gmail.com>
Date: 2024-04-12T00:56:54Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > On 2024-04-11 16:35:58 -0400, Tom Lane wrote: >> Indeed. I recall reading, not long ago, some Linux kernel docs to the >> effect that automatic stack growth is triggered by a reference into >> the page just below what is currently mapped as your stack, and >> therefore allocating a stack frame greater than one page has the >> potential to cause SIGSEGV rather than the desired stack extension. > I think it's more than a single page, but I'm not entirely sure either. I > think some compilers inject artificial stack accesses when extending the stack > by a lot, but I don't remember the details. Hmm. You're right that I was misremembering the typical RAM page size. The kernel must be allowing stack frames bigger than 4K, or we'd see problems everywhere. I wonder how much bigger ... > frame size warnings > 4096 155 > 8192 111 > 16384 36 > 32768 14 > 65536 8 > Suggests that starting somewhere around 16-32k might be reasonable? I'm hesitant to touch more than a handful of places on the strength of the info we've got; either it's wasted work or it's not enough work, and we don't know which. Might be time for some experimentation. regards, tom lane
Commits
-
Don't allocate large buffer on the stack in pg_verifybackup
- 929c05774b51 17.0 landed