Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGVaS-0006Zj-GB for pgsql-admin@arkaria.postgresql.org; Thu, 01 Jun 2017 19:16:48 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dGVaR-00063O-PN for pgsql-admin@arkaria.postgresql.org; Thu, 01 Jun 2017 19:16:47 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dGVaR-00063F-BQ for pgsql-admin@postgresql.org; Thu, 01 Jun 2017 19:16:47 +0000 Received: from mail-qt0-x22f.google.com ([2607:f8b0:400d:c0d::22f]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dGVaO-0007pL-OS for pgsql-admin@postgresql.org; Thu, 01 Jun 2017 19:16:46 +0000 Received: by mail-qt0-x22f.google.com with SMTP id w1so17018170qtg.2 for ; Thu, 01 Jun 2017 12:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=eoB0/DdI9ok54noiVz/vh0eZRKurroaSxl06AJWSLxc=; b=Ps+cxvr4TDJivmnVP+FQOoRg3sHCdzwnI0CO62QDLeHDf22dDupt93xaiRM4J1aw8g qqFMkBZjeJKRVsBYGm9rAueEv7D+I/OVewwmZhgjAbSJMH1WamMUivHkDPtfeOEsYwRq 7CPES6pXlzePPsrjtdzQP30uNw1vK8PoN3MF+CkdVQ5uvAGHWohvB3DKM+hB4V02k1Au lny9CpGVK7Utxh/8MfKwzMU5ev4/GVqaaM+bMtqiK8CxudlvWsnstdQAaUcgMRMrgasr 6TOorzIis1p2VPxJ7TExLa/LF3TRWO0HHVIEkYvQ4dSYRlN9VmxuJ26fho4s2IZkRPdg 8V+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=eoB0/DdI9ok54noiVz/vh0eZRKurroaSxl06AJWSLxc=; b=LIjh+g/ilZortj1V9OYjbLNcITSCqpaZEA7SIy3oewz6l253iXkXC5JSzMW3GDTVon 2JRyslUPz70cZYfv5LzMspK36Z2uSuqCPUjozjxcGwpKDhLu2oU9N4jkRAmB9ZjFMMtb S98WxXyKHr7AsXhyWmwG6T0BC44ry6TUdKFCnCPjQaLYemQzaxRcj8P1uf10MJYWxXwe AXIqG6YhhkAadFZLI586QY2vvKo9KIuOcTC+oQRu7jWMtVxVriQZXkE8S4DQzTz+CLcp 83C8srC6IJEcUtpxda7vB00vExeUVy9DlXvVsZ3GroMs1ZSQSZa7nHbOuOAdfX5lndu9 peIg== X-Gm-Message-State: AODbwcCj147RG0fxGdgGKbkgX2SJ8oAE2e1K7He9FhwavrIdS8t61j/U VuLAqTOOq3KX2uh1Wt8= X-Received: by 10.200.49.194 with SMTP id i2mr3803664qte.156.1496344603197; Thu, 01 Jun 2017 12:16:43 -0700 (PDT) Received: from alvin.alvh.no-ip.org ([179.57.115.10]) by smtp.gmail.com with ESMTPSA id s21sm13240157qtc.58.2017.06.01.12.16.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Jun 2017 12:16:42 -0700 (PDT) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id 70753348; Thu, 1 Jun 2017 15:16:40 -0400 (-04) Date: Thu, 1 Jun 2017 15:16:40 -0400 From: Alvaro Herrera To: Mahesh Jhala Cc: "pgsql-admin@postgresql.org" Subject: Re: Can manual vacuuming conflict with auto vacuuming? Message-ID: <20170601191640.rj6zda65pd5tgjrg@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0) X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org Mahesh Jhala wrote: > Hello All, > > If autovacuum of a large PostgreSQL table is in progress, and I start > a manual vacuum on the table, is there likely to be a conflict > (locking etc.) between the two vacuums? It depends on the autovacuum being for-wraparound or not. If not, then the conflict will be detected within one second and autovacuum will cancel itself, so the regular vacuum would be able to proceed. So there is a one-second period of time during which you would see the manual vacuum as blocked by autovacuum. If autovacuum is for wraparound protection, then it won't cancel itself, and the regular vacuum will just wait until autovacuum is finished. There is a final stage in vacuuming (both auto and regular) during which the table is truncated (the last few empty pages, if any). There's some heuristics to handle that case nowadays which I don't remember very clearly. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin