From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | <alvherre(at)alvh(dot)no-ip(dot)org>, <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: database vacuum from cron hanging |
Date: | 2005-10-11 21:58:35 |
Message-ID: | s34bef41.089@gwmta.wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
(gdb) p BufferDescriptors[781]
$1 = {tag = {rnode = {spcNode = 1663, dbNode = 16385, relNode = 2666}, blockNum = 1}, flags = 70, usage_count = 5, refcount = 4294967294,
wait_backend_pid = 748, buf_hdr_lock = 0 '\0', buf_id = 781, freeNext = -2, io_in_progress_lock = 1615, content_lock = 1616}
>>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 10/11/05 4:51 PM >>>
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> Trivial observation: process 748 is a manually-issued VACUUM (manually,
> by cron), it's holding locks other VACUUMs are waiting for, and is
> waiting on LockBufferForCleanup. I guess this means it lost a signal,
> or somebody else is holding a pin on the buffer. If this is the case,
> who is it and why isn't it releasing the pin?
Yeah, this is clearly the problem --- the other guys waiting are just
queued up behind this one.
If the system is still in that state, could you reattach to the stuck
process and do
p BufferDescriptors[781]
It might be good to do
p BufferDescriptors[782]
as well --- I am not sure offhand whether LockBufferForCleanup takes
a 0-based or 1-based index, and in any case it's possible gcc would
have done something weird with the variable contents. You should
see wait_backend_pid = 748 in the one we want.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-10-11 23:27:26 | Re: database vacuum from cron hanging |
Previous Message | Tom Lane | 2005-10-11 21:51:53 | Re: database vacuum from cron hanging |