In postmaster.c signal handler pmdie() calls ereport() and
errmsg_internal(), which could call palloc() then malloc() if
necessary. Because it is possible that pmdie() gets called while
malloc() gets called in postmaster, I think it is possible that a
deadlock situation could occur through an internal locking inside
malloc(). I have not observed the exact case in PostgreSQL but I see a
suspected case in Pgpool-II. In the stack trace #14, malloc() is
called by Pgpool-II. It is interrupted by a signal in #11, and the
signal handler calls malloc() again, and it is stuck at #0.

So my question is, is my concern about PostgreSQL valid?
If so, how can we fix it?

#0  __lll_lock_wait_private () at 
#1  0x00007f67fe20ccba in _L_lock_12808 () from /lib/x86_64-linux-gnu/
#2  0x00007f67fe20a6b5 in __GI___libc_malloc (bytes=15) at malloc.c:2887
#3  0x00007f67fe21072a in __GI___strdup (s=0x7f67fe305dd8 "/etc/localtime") at 
#4  0x00007f67fe239f51 in tzset_internal (always=<optimized out>, 
    at tzset.c:444
#5  0x00007f67fe23a913 in __tz_convert (timer=timer@entry=0x7ffce1c1b7f8, 
    use_localtime=use_localtime@entry=1, tp=tp@entry=0x7f67fe54bde0 <_tmbuf>) 
at tzset.c:632
#6  0x00007f67fe2387d1 in __GI_localtime (t=t@entry=0x7ffce1c1b7f8) at 
#7  0x000000000045627b in log_line_prefix (buf=buf@entry=0x7ffce1c1b8d0, 
line_prefix=<optimized out>, 
    edata=<optimized out>) at ../../src/utils/error/elog.c:2059
#8  0x000000000045894d in send_message_to_server_log (edata=0x753320 
    at ../../src/utils/error/elog.c:2084
#9  EmitErrorReport () at ../../src/utils/error/elog.c:1129
#10 0x0000000000456d8e in errfinish (dummy=<optimized out>) at 
#11 0x0000000000421f57 in die (sig=2) at protocol/child.c:925
#12 <signal handler called>
#13 _int_malloc (av=0x7f67fe546760 <main_arena>, bytes=4176) at malloc.c:3302
#14 0x00007f67fe20a6c0 in __GI___libc_malloc (bytes=4176) at malloc.c:2891

Best regards,
Tatsuo Ishii
SRA OSS, Inc. Japan

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to