award@dominionsciences.com writes:
> 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).
Hm. Postgres does sometimes issue elog messages from inside a signal
handler. I doubt that it would do so while interrupting a non-interrupt
elog issuance, but wouldn't swear to it.
> 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.
Postgres doesn't, but that doesn't mean that your glibc wouldn't
internally assume that it might be in a threaded app. See the recent
flamewar about threaded vs unthreaded libc in pgsql-hackers.
It's really too bad that your gdb backtrace didn't show anything past
the write_syslog level (which is an elog subroutine). If we could see
whether the elog had been issued from a signal handler, and if so what
it had interrupted, we'd have an idea whether this is a known syslog
deficiency or not. Do you want to rebuild with debug symbols and try
the backtrace again?
> 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!
Agreed, but we might be looking at needing to do that in Postgres, if
this turns out to be something that the glibc boys know about and won't
fix.
regards, tom lane
