Re: ANALYZE locks pg_listener in EXCLUSIVE for long

At 01:46 PM 3/05/2004, Tom Lane wrote:
>If it takes half an hour to ANALYZE pg_listener, I think that ANALYZE is
>not your real problem :-(.  You need a much more aggressive vacuuming
>policy on that table.  Maybe a cron job issuing "vacuum pg_listener"
>once a minute would do?  And get the size of the table knocked down to
>something less stratospheric to begin with --- perhaps stop all the
>listeners while you TRUNCATE the table.

It's a general ANALYZE command for the entire DB. It's about 6GB in size, 
and is vacuumed as frequently as possible; there is certainly unreclaimed 
space, but it does not substantially outweigh used space. My *guess* is 
that the largest table is being ANALYZEd at the time (it uses most of the 
6GB), and for some reason pg_listeners is being locked in ACCESS SHARE the 
entire time.

Just vacuuming pg_listener produces:

vacuum verbose pg_listener;
INFO:  vacuuming "pg_catalog.pg_listener"
INFO:  "pg_listener": found 0 removable, 0 nonremovable row versions in 0 pages
VACUUM


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 03 5330 3172          |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                 |    --________--
PGP key available upon request,  |  /
and from pgp.mit.edu:11371       |/