blocking automatic vacuum

Hi,

last ween i've seen a blocking "automatic vacuum".
as i understood, this is not supposed to happen. in the past i saw vacuum
processes disappear, in case of the need of a lock.

this is the relvant extract from the log and the database:
2010-06-18 18:33:36.011 CEST 172.19.5.34(57414) gc:29274
143897560 LOG: process 29274 still waiting for RowExclusiveLock on
relation 42964239 of database 19759903 after 1002.601 ms
...
2010-06-18 19:23:43.898 CEST :20892 0 LOG: automatic
vacuum of table "gd.pg_toast.pg_toast_42964236": index scans: 1
pages: 1469113 removed, 288899 remain
tuples: 369645 removed, 396719 remain
system usage: CPU 5.46s/0.85u sec elapsed 13785.76 sec
2010-06-18 19:23:43.899 CEST 172.19.5.22(45561) gc:315
143897590 LOG: process 315 acquired RowExclusiveLock on relation
42964239 of database 19759903 after 3007903.169 ms
2010-06-18 19:23:43.920 CEST 172.19.5.22(45561) gc:315
143897590 LOG: duration: 3007924.883 ms execute <unnamed>: insert
into SHARED_GAMESET .....

gd=# select oid,* from pg_class where reltoastrelid=42964239;
relname | relnamespace | reltype | relowner | relam | relfilenode |
reltablespace | relpages | reltuples | reltoastrelid | reltoastidxid |
relhasindex | relisshared | relistemp | relkind | relnatts | relchecks | rel
hasoids | relhaspkey | relhasrules | relhastriggers | relhassubclass |
relfrozenxid | relacl | reloptions
----------------+--------------+----------+----------+-------+-------------+---------------+----------+-------------+---------------+---------------+-------------+-------------+-----------+---------+----------+-----------+----
--------+------------+-------------+----------------+----------------+--------------+----------------------------------------+------------
shared_gameset | 19760303 | 42964238 | 16443 | 0 | 42964236
| 0 | 143715 | 1.96642e+06 | 42964239 | 0 |
t | f | f | r | 4 | 0 | f
| t | f | f | f |
101290258 | {gdadm=arwdDxt/gdadm,gc=arwdDxt/gdadm} |
(1 row)

So what's this?
from my point of view the vacuum blocked inserts on this table for about 50
minutes.
Is this a bug?
Or do yuo see here a configuration issue?

best regards,
Uwe

Uwe Bartels
Systemarchitect - Freelancer
mailto: uwe.bartels at gmail.com