Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 66EB46327F0 for ; Wed, 4 Nov 2009 19:52:28 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 30675-01 for ; Wed, 4 Nov 2009 23:52:20 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mail.postgresql.org (Postfix) with ESMTP id C25C4633A4E for ; Wed, 4 Nov 2009 19:52:19 -0400 (AST) Received: by ey-out-2122.google.com with SMTP id d26so1428238eyd.33 for ; Wed, 04 Nov 2009 15:52:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=5uGOxgB9LVITHEZOcr7VglXjipb+Lw/WHjvPddiwCH0=; b=A21RoO/AJTPAg55DadU3e1b3NSEyG/ESVDP417y1Npb7b41a6998vyJdSSLZEb3d2U /Z2tphK8sdL/7RO+n/6XspGb584RoTnw4ugO1b5dxtMtG2iwPb2LQhocEa9ZUzAdtMmy j042ImNaOEZ+NDDKD4K807A298cR/0oA/7keY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=wVmUGREvhycS/oez2+vBwX2LumcQwu1i+fkOla8tQbnj/rjyIjwn88WXa7CrQwTo7/ XTm8yU8lLC9COVtmhjBUPxNSxfphelmW44W91x2kFLkZqQPFiz7+UOzJ62ZpXhauLx/M hxxE74tYzOmOhEtc9w5gFPZp1/rg8vW1v8QsM= MIME-Version: 1.0 Received: by 10.216.93.68 with SMTP id k46mr663612wef.161.1257378737265; Wed, 04 Nov 2009 15:52:17 -0800 (PST) Date: Wed, 4 Nov 2009 17:52:17 -0600 Message-ID: Subject: Followup: vacuum'ing toast From: Dave Crooke To: pgsql-performance Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.11 tagged_above=-10 required=5 tests=BAYES_05=-1.11 X-Spam-Level: X-Archive-Number: 200911/53 X-Sequence-Number: 36221 Thanks folks for the quick replies. 1. There is one transaction, connected from the JVM, that is showing "IDLE in transaction" .... this appears to be a leftover from Hibernate looking at the schema metadata. It's Apache Jackrabbit, not our own code: hyper9test_1_6=# select c.relname, l.* from pg_class c, pg_locks l where c.relfilenode=l.relation and l.pid in (select procpid from pg_stat_activity where current_query=' in transaction'); relname | locktype | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid | mode | granted ----------------------------+----------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+------+-----------------+--------- pg_class_oid_index | relation | 280066 | 2662 | | | | | | | | 3/18 | 8069 | AccessShareLock | t pg_class_relname_nsp_index | relation | 280066 | 2663 | | | | | | | | 3/18 | 8069 | AccessShareLock | t pg_description_o_c_o_index | relation | 280066 | 2675 | | | | | | | | 3/18 | 8069 | AccessShareLock | t pg_namespace_nspname_index | relation | 280066 | 2684 | | | | | | | | 3/18 | 8069 | AccessShareLock | t pg_namespace_oid_index | relation | 280066 | 2685 | | | | | | | | 3/18 | 8069 | AccessShareLock | t pg_class | relation | 280066 | 1259 | | | | | | | | 3/18 | 8069 | AccessShareLock | t pg_description | relation | 280066 | 2609 | | | | | | | | 3/18 | 8069 | AccessShareLock | t pg_namespace | relation | 280066 | 2615 | | | | | | | | 3/18 | 8069 | AccessShareLock | t version_node | relation | 280066 | 493309 | | | | | | | | 3/18 | 8069 | AccessShareLock | t version_node_idx | relation | 280066 | 493315 | | | | | | | | 3/18 | 8069 | AccessShareLock | t (10 rows) Since the Jackrabbit tables are in the same namespace / user / schema as ours, am I right in thinking that this is effectively blocking the entire auto-vaccum system from doing anything at all? Cheers Dave