Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id B8F66F64990 for ; Tue, 24 Jul 2012 14:08:55 -0300 (ADT) Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1StibM-0006vq-OF for pgsql-admin@postgresql.org; Tue, 24 Jul 2012 17:08:54 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id q6OH8ZWO024029; Tue, 24 Jul 2012 13:08:35 -0400 (EDT) From: Tom Lane To: Gary Webster cc: pgsql-admin@postgresql.org, "Joshua D. Drake" Subject: Re: db size growing out of control when using clustered Jackrabbit In-reply-to: References: <500DC4BB.2090102@commandprompt.com> Comments: In-reply-to Gary Webster message dated "Tue, 24 Jul 2012 11:58:53 -0400" Date: Tue, 24 Jul 2012 13:08:35 -0400 Message-ID: <24028.1343149715@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201207/67 X-Sequence-Number: 39784 Gary Webster writes: > By "routine maintenance", do you mean autovacuum, or something else? > Autovacuum does appear to usually get 'auto-canceled' by a lock. That's bad and you should look into the reason why it happens. Ordinary DML (CRUD) operations should not kick autovac off a table. If it's happening, it's probably because something is fooling with the table's schema, which doesn't seem like something you want to have happening during routine operations; especially not on tables that are large enough for this to be an issue in the first place. Or it might be something doing a LOCK TABLE as a substitute for more fine-grained locking; which again is bad for performance reasons that have nothing to do with hobbling autovacuum. regards, tom lane