Re: database vacuum from cron hanging

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: database vacuum from cron hanging
Date: 2005-10-11 21:51:53
Message-ID: 24241.1129067513@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2005-10-11 21:58:35 Re: database vacuum from cron hanging
Previous Message Kevin Grittner 2005-10-11 21:37:23 Re: slower merge join on sorted data chosen over