locked backend - Mailing list pgsql-general

Hi all,

I've had today a strange lockup on our postgres data base.

Postgres 8.0.3
Debian GNU/Linux 3.1
autovacuum set up

The situation (diagnosed via pg_stat_activity): one table was locked by
an update, a VACUUM ANALYZE was running for the same table (triggered by
autovacuum), and a handful of inserts were waiting on the same table.
After some checking around (see below for details), I decided to kill
the UPDATE (it was holding up the inserts which means lost data for us
and danger of connection starvation), and did it with "kill processid"
from the command line, but no success: the backend didn't respond. Then
I killed the VACUUM which exited promptly, the UPDATE was still blocked.
Then I remembered there is a pg_cancel_backend function (seen it
recently on this list), and tried that too, without success - the update
was still blocked, and blocking all inserts.

In this situation I decided to kill -9 the blocked backend, knowingly
that this will basically restart the data base server, which did happen.
Only it took a veeeery long time to come up again (~15-20 minutes),
which I also find very strange...

Now my actual question is: what can cause a backend to block so that it
won't answer to kill or pg_cancel_backend ? Is there any other solution
than kill -9 in these situations ? I'm pretty sure the update would
never have finished, the box was mostly idle when I did all this, so I
can exclude that the update was busy working. I actually have seen this
a few times before, and had to do the same kill -9 to get back on track.

Some details of the circumstances this happened:

I'm attaching a file with some diagnostic output, together with the SQLs
used to get them. I also checked ps on the command line to make sure the
pg_stat_activity is not reporting phantom SQLs (as I had some occasions
it did). Unfortunately the attached diagnostic is not complete, as I
forgot to save it from the beginning, and some of it rolled out of my
terminal's buffer... particularly, the VACUUM is not visible anymore, I
already killed it by then.

As you see, the update was the oldest query running (and for more than 3
hours too !!!), and when I looked first there was a VACUUM also running,
being the immediate oldest entry after the UPDATE. The inserts came
after it, and checking their locks, they were waiting for a lock on the
"problem_table", I don't remember exactly what kind of lock.

I have no clue as of what's happening here, so I would be grateful for
any help in diagnosing this further...

Maybe I should mention that with the same data base (but a different box
!) I have already seen this behavior 1-2 times, and 2 times the system
locked up completely (the machine was not answering even for ssh, but
then after restart nothing was suspect, an extensive hardware test did
not find anything either).

TIA for any help.

Cheers,
Csaba.