On 2016-05-05 15:56:45 -0400, Tom Lane wrote:
> Andres Freund <and...@anarazel.de> writes:
> >> #0  0x00000008014321d7 in sbrk () from /lib/libc.so.7
> >> #1  0x0000000801431ddd in sbrk () from /lib/libc.so.7
> >> #2  0x000000080142e5bb in sbrk () from /lib/libc.so.7
> >> #3  0x000000080142e085 in sbrk () from /lib/libc.so.7
> >> #4  0x000000080142de28 in sbrk () from /lib/libc.so.7
> >> #5  0x000000080142e1cf in sbrk () from /lib/libc.so.7
> >> #6  0x0000000801439815 in free () from /lib/libc.so.7
> >> #7  0x000000080149e3d6 in nsdispatch () from /lib/libc.so.7
> >> #8  0x00000008014a41c6 in __cxa_finalize () from /lib/libc.so.7
> >> #9  0x000000080144525c in exit () from /lib/libc.so.7
> >> #10 0x00000000008e1bc2 in quickdie (postgres_signal_arg=3) at 
> >> postgres.c:2623
> >> #11 <signal handler called>
> >> #12 0x0000000801431847 in sbrk () from /lib/libc.so.7
> > That looks like independent issue, namely that we're trigger memory
> > allocations from a signal handler (see frames 12, 11, 10, 9). Presumably
> > due to system registered atexit handlers.  I suspect we should be using
> > _exit() here?  Tom?
> I don't think that would improve matters.  In the first place, if we use
> _exit() here that might encourage third-party extension authors to believe
> they should use _exit(), which would be bad.

The sourcetree already has a number of _exit() calls, so I don't think
that'd make a meaningfull difference.

> In the second place, we don't know what it is we're skipping by not
> running atexit handlers, and again that could be bad.

I've a hard time coming up with a scenario where that'd be a problem in
a PANIC case. Isn't it pretty common to use _exit after fatal errors
(and forks)?

> In the third place, by the time we
> get to the exit() call we've already exposed ourselves to a whole lot of
> such hazards by running ereport() (including sending a message to the
> client!).

True. And that's not good. But the magic of ErrorContext shields us from
a fair amount of issues.

> In the fourth place, if we've received a quickdie interrupt,
> it doesn't actually matter if the process crashes; we just want it to
> quit ASAP.

If it always were crashing, that'd be somewhat fine. But sbrk internally
uses mutexes, so this can result in processes getting stuck. And that is
a problem.  There've actually been reports about that every now and then.


Andres Freund

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to