Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XCVVn-0004LC-Vd for pgsql-bugs@arkaria.postgresql.org; Wed, 30 Jul 2014 15:09:52 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XCVVn-00028i-2T for pgsql-bugs@arkaria.postgresql.org; Wed, 30 Jul 2014 15:09:51 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XCVVm-00028X-3L; Wed, 30 Jul 2014 15:09:50 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XCVVd-0005zM-Nr; Wed, 30 Jul 2014 15:09:49 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id s6UF9bXJ029728; Wed, 30 Jul 2014 11:09:37 -0400 From: Tom Lane To: David G Johnston cc: pgsql-admin@postgresql.org, pgsql-bugs@postgresql.org Subject: Re: [ADMIN] Can postgres run autovacuum tasks when autovacuum is disabled? In-reply-to: <26640.1406723887@sss.pgh.pa.us> References: <1406707245323-5813258.post@n5.nabble.com> <26640.1406723887@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Wed, 30 Jul 2014 08:38:07 -0400" Date: Wed, 30 Jul 2014 11:09:37 -0400 Message-ID: <29727.1406732977@sss.pgh.pa.us> X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-bugs Precedence: bulk Sender: pgsql-bugs-owner@postgresql.org I wrote: > However ... it looks to me like if the autovac launcher gets launched > forcibly because of a possible wraparound issue, it will keep running > normally after that even if autovacuum is off :-(. Nope, scratch that: I missed the bit before the launcher's main loop, where it fires off one child and exits if it's launched when autovacuum is already false. Still, if it does fire one child process, it looks like that child will vacuum everything that seems to need vacuuming in the target database. We should probably adjust that so that tables not in danger of wraparound get skipped. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs