Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 9772A64FD5F for ; Wed, 17 Dec 2008 11:28:46 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 96381-06 for ; Wed, 17 Dec 2008 11:28:43 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from lists.commandprompt.com (host-159.commandprompt.net [207.173.203.159]) by mail.postgresql.org (Postfix) with ESMTP id 46F8764FD3B for ; Wed, 17 Dec 2008 11:28:42 -0400 (AST) Received: from perhan.alvh.no-ip.org (200-126-65-108.bk5-dsl.surnet.cl [200.126.65.108]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id mBHFXd6n027859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2008 07:33:42 -0800 Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 73DBC47CCD; Wed, 17 Dec 2008 12:28:30 -0300 (CLST) Date: Wed, 17 Dec 2008 12:28:30 -0300 From: Alvaro Herrera To: John Lister Cc: Tom Lane , pgsql-admin@postgresql.org Subject: Re: controlling autovacuum during the day. Message-ID: <20081217152830.GD4453@alvh.no-ip.org> References: <2BB7361E57C4417A975C0474610BA4C3@squarepi.com> <27759.1229521625@sss.pgh.pa.us> <742A9D77A1BA4171AF52BBBF6F5F2C75@squarepi.com> <28510.1229525243@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Wed, 17 Dec 2008 07:33:42 -0800 (PST) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200812/127 X-Sequence-Number: 30960 John Lister wrote: > bizarre... Its been turned off for a while, but from memory the > autovacuum process was causing the table it was running on to be locked > - I assumed this was an equivalent to VACUUM FULL - causing all other > connections to wait until it had finished. Could this happen another way, > i thought the other vacuum options acted passively... I'll turn it back > on and see what happens... Maybe you're doing ALTER TABLE or something else that is blocked behind vacuum? Vacuum doesn't block INSERT, UPDATE or DELETE, but it can block other operations that want exclusive locks on the table. What Postgres version is this anyway? -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support