>> And the other:
>> 19720 pts/2 S 0:04 postgres: award Trucking [local] UPDATE
>> (gdb) bt
>> #0 0x4021cec6 in sigsuspend () from /lib/libc.so.6
>> #1 0x424b6218 in __pthread_wait_for_restart_signal ()
>> from /lib/libpthread.so.0
>> #2 0x424b79a0 in __pthread_alt_lock () from /lib/libpthread.so.0
>> #3 0x424b4c17 in pthread_mutex_lock () from /lib/libpthread.so.0
>> #4 0x402ca21c in vsyslog () from /lib/libc.so.6
>> #5 0x402c9d8f in syslog () from /lib/libc.so.6
>> #6 0x08150a57 in write_syslog ()
>> (gdb)
>
> This seems worthy of an inquiry to the glibc maintainers, or at least
> some research to find out what syslog() could block on.
I've been digging, and the best information I've been able to come up with
is that there may be an unresolved glibc bug involving syslog and threads
dating back to at least 2001, or that glibc's syslog() is not re-entrant
and deadlocks when called from inside a signal handler when already
executing. Neither of those make a whole lot of sense to me, though:
1. The Postgresql backend shouldn't be getting any signals (at least none
external to Postgresql).
2. Postgresql doesn't use threads, right? That occurred to me this
morning, and I'm a little disturbed by the appearance of libpthread in the
backtrace.
The disgusting thing is that all the mail threads I've followed either
dead-end, or mention creating a signal-safe and/or thread-safe wrapper
around syslog inside to the calling application. Yuck! The only
information I've found which was particularly enlightening was a mention
that POSIX doesn't specify that syslog() should be reentrant, and
(according to the poster) glibc is not and does not specify (which I
confirmed in the on-line manual).
Blah. I'm ready to chalk this one up to glibc inadequacies and put it
behind me now, especially when the simple adjustment of
pipe-to-log-rotator does just fine.