Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault

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