"Arthur Ward" <award@dominionsciences.com> writes:
> FWIW, since I already went to the trouble (and for the sake of people
> searching the archives in the future), here's what I was seeing in the
> backtraces after rebuilding this afternoon:
> This process:
> 19763 pts/2 S 0:00 postgres: checkpoint subprocess
> Was stuck here:
> (gdb) bt
> #0 0x402cf077 in semop () from /lib/libc.so.6
> (gdb)
Hmm. It's odd that gdb isn't showing a backtrace any deeper than that
--- are you sure you rebuilt with debug symbols enabled? But anyway,
I'd say this process is just waiting for someone else to release a lock.
Likely the lock holder is this other process:
> 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.
regards, tom lane