Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 850DC64FD5F for ; Wed, 17 Dec 2008 11:43:03 -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 99109-05 for ; Wed, 17 Dec 2008 11:43:00 -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 1A22A64FD3B for ; Wed, 17 Dec 2008 11:42:59 -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 mBHFlu5W029677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2008 07:47:59 -0800 Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id ADA5647CCD; Wed, 17 Dec 2008 12:42:47 -0300 (CLST) Date: Wed, 17 Dec 2008 12:42:47 -0300 From: Alvaro Herrera To: John Lister Cc: pgsql-admin@postgresql.org Subject: Re: controlling autovacuum during the day. Message-ID: <20081217154247.GE4453@alvh.no-ip.org> References: <2BB7361E57C4417A975C0474610BA4C3@squarepi.com> <27759.1229521625@sss.pgh.pa.us> <742A9D77A1BA4171AF52BBBF6F5F2C75@squarepi.com> <28510.1229525243@sss.pgh.pa.us> <20081217152830.GD4453@alvh.no-ip.org> 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:48:00 -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/129 X-Sequence-Number: 30962 John Lister wrote: >> 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? > > Now running 8.3, but this was on 8.2. That doesn't help isolating the problem; 8.3 autovacuum behavior is very different from 8.2. Please enable it, see how it goes, and report back if anything seems amiss. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.