A checkpoint would also have reason to wait for a page-level lock, if
the stuck backend was holding one. I am wondering though if the stuck
condition consistently happens while trying to fire a trigger? That
would be very interesting ... not sure what it'd mean though ...
Hmm. I'm really at
Arthur Ward [EMAIL PROTECTED] writes:
I'm back with more on the funky glibc-syslog-Postgres deadlocking behavior:
It looks to me like the guy doing VACUUM is simply waiting for the other
guy to release a page-level lock. The other guy is running a deferred
trigger and so I'd expect him to be
Arthur Ward [EMAIL PROTECTED] writes:
An idea just popped into my head, though. Perhaps I can create procedures
in plpgsql and plpython which do nothing but spew notices (which would in
turn be sent to syslog), and run one or two copies to see if they'll die
on their own given sufficient time.
It looks to me like the guy doing VACUUM is simply waiting for the other
guy to release a page-level lock. The other guy is running a deferred
trigger and so I'd expect him to be holding one or two page-level locks,
on the page or pages containing the tuple or tuples passed to the
trigger.
I'm back with more on the funky glibc-syslog-Postgres deadlocking behavior:
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
Arthur Ward [EMAIL PROTECTED] writes:
It looks to me like the guy doing VACUUM is simply waiting for the other
guy to release a page-level lock. The other guy is running a deferred
trigger and so I'd expect him to be holding one or two page-level locks,
on the page or pages containing the
Arthur Ward [EMAIL PROTECTED] 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/2S 0:00 postgres: checkpoint
And the other:
19720 pts/2S 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
[EMAIL PROTECTED] 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
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
I'm encountering strange hangs in postgresql backends at random moments.
They seem to be associated with attempts to issue log entries via syslog.
I have run backtraces on the hung backends a few times, and they routinely
trace into system libraries where it looks like a stuck syslog call. So
far,
Arthur Ward [EMAIL PROTECTED] writes:
I'm encountering strange hangs in postgresql backends at random moments.
They seem to be associated with attempts to issue log entries via syslog.
I have run backtraces on the hung backends a few times, and they routinely
trace into system libraries where
Arthur Ward [EMAIL PROTECTED] writes:
I'm encountering strange hangs in postgresql backends at random moments.
They seem to be associated with attempts to issue log entries via syslog.
I have run backtraces on the hung backends a few times, and they routinely
trace into system libraries where
Arthur Ward [EMAIL PROTECTED] writes:
I'm encountering strange hangs in postgresql backends at random
moments. They seem to be associated with attempts to issue log entries
via syslog. I have run backtraces on the hung backends a few times,
and they routinely trace into system libraries where
14 matches
Mail list logo
