Hung Vacuum in 8.3
| От | Mark Kirkwood |
|---|---|
| Тема | Hung Vacuum in 8.3 |
| Дата | |
| Msg-id | 4D6330E9.6030809@catalyst.net.nz обсуждение исходный текст |
| Ответы |
Re: Hung Vacuum in 8.3
|
| Список | pgsql-bugs |
This is 8.3.14 on Debian Lenny x86-64.
I'm seeing a hung vacuum:
postgres=# select procpid, query_start,waiting, current_query from
pg_stat_activity where current_query like '%VACUUM%';
procpid | query_start | waiting
|
current_query
--------+-------------------------------+---------+---------------------------------------------------------------------------------------------
7347 | 2011-02-22 06:02:02.400247+13 | f | VACUUM ANALYZE;
at approx 1300 (so it has been sitting there for approx 7 hours, normal
database vacuum time is 10 minutes). Now according to pg_stat_activity
and pg_locks it is *not* waiting for a lock, but no vacuuming appears to
be going on. strace says:
$ strace -p 7347
Process 7347 attached - interrupt to quit
semop(33456157, 0x7ffff512bad0, 1
Ok, so we are waiting on a semaphore - hmm, why is it not showing up as
waiting on a lock of some kind?
Of interest is this:
postgres=# select procpid, query_start, current_query from
pg_stat_activity order by query_start limit 1;
procpid | query_start
| current_query
---------+-------------------------------+-------------------------------------------------------------------------------------
25953 | 2011-02-22 04:24:07.417138+13 | SELECT n.node_id, n.node_ --
long query, joining several large tables - text snipped
So this guy had been running from before the vacuum started, so probably
vacuum is wanting to do lazy_truncate_heap() on one of the tables in the
join (no gdb on this box unfortunately). I am however still puzzled
about why no locks are being waited on.
I have canceled the vacuum, but any suggestions for getting more diag
info for next time?
regards
Mark
В списке pgsql-bugs по дате отправления: