Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g3PTE-0004hF-NG for pgsql-hackers@arkaria.postgresql.org; Fri, 21 Sep 2018 17:44:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1g3PTC-0001RW-G4 for pgsql-hackers@arkaria.postgresql.org; Fri, 21 Sep 2018 17:43:58 +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.89) (envelope-from ) id 1g3PTA-0001RP-Cs for pgsql-hackers@lists.postgresql.org; Fri, 21 Sep 2018 17:43:58 +0000 Received: from new2-smtp.messagingengine.com ([66.111.4.224]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g3PT6-0007fg-FK for pgsql-hackers@lists.postgresql.org; Fri, 21 Sep 2018 17:43:55 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.nyi.internal (Postfix) with ESMTP id 57A3F2BB0; Fri, 21 Sep 2018 13:43:50 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 21 Sep 2018 13:43:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=L2ljZnhlU4DPcDENO3kR09wNIfjCQcXWfrcGboXBPpQ=; b=uLwbupz5 yTCf2H06FclzIDRUOvj86Z4EftduC/cSrPeMI2g043RjuCJ1UFqM1R5qDsvX+PPv HBnrKSQMhb5oxHZuaBUAOObPzrf79B1Af3DGd8LC9VPw/4IjHvrIm/3YRQMFgb8T m1ORWGu25UJ1r9U2OLZk93YZYVitK9nQYzhNQV3oiJrK29heKd2OQebZHWfNf75Z ciVKmkJ2uuSiGPobFCRTKdJocnxMG8ElH60LK2t/ildViehQek8EtZGtEkSEx6BO cDu6CKDn/oCgdEbvqrsz42H2ly44f0z+LZjVx+t//WmqcEmwAl2Bc9NP1TyNLVaf hVwRJsSpn/Xd9A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=L2ljZnhlU4DPcDENO3kR09wNIfjCQ cXWfrcGboXBPpQ=; b=wYnUuXlbjDHCYhROqhcDGp0GbO4zMVSnf9vr2vaqx0WzB 6K9efpPr7c68QYUfb+yzxiQ++Tz1TwlF8nTyqvifJBqIJH4tTseCUdcOKAYxRY7r Cc5+NenLzZo1BLR45tzjzfc4UNVZp1ObndOCPSYs9mEmSNSsaqs6z/+sby8lZqZZ uqpmpcezFnTA/+a826EWVPt4/NDKAY6Y6IcXc+TqCQIk3fwUcflgPsfNf0z3ie0C LESups2pLObglx+KlO3+mSkOXwm65i8kqn205efwpGJHCs1N1pgaWAmfSzSMZD4F mxC8/f1NcpG+v25NUcc5FWkRmO3x2/6Sp8riE8nyg== X-ME-Proxy: X-ME-Sender: Received: from intern.anarazel.de (c-98-210-140-171.hsd1.ca.comcast.net [98.210.140.171]) by mail.messagingengine.com (Postfix) with ESMTPA id 480BCE47C2; Fri, 21 Sep 2018 13:43:49 -0400 (EDT) Date: Fri, 21 Sep 2018 10:43:47 -0700 From: Andres Freund To: Sergei Kornilov Cc: Robert Haas , Alvaro Herrera , Michael Paquier , PostgreSQL Hackers Subject: Re: pgsql: Improve autovacuum logging for aggressive and anti-wraparound ru Message-ID: <20180921174347.wvszsn7uk56zvz7o@alap3.anarazel.de> References: <20180914153554.562muwr3uwujno75@alvherre.pgsql> <7924791537551496@myt5-c56023d17c6b.qloud-c.yandex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7924791537551496@myt5-c56023d17c6b.qloud-c.yandex.net> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, On 2018-09-21 20:38:16 +0300, Sergei Kornilov wrote: > > My first question was whether TWO of them were dead code ... isn't an > > aggressive vacuum to prevent wraparound, and a vacuum to prevent > > wraparound aggressive? > Maybe i am wrong, aggressive autovacuum was your commit. > Message split was in b55509332f50f998b6e8b3830a51c5b9d8f666aa > Aggressive autovacuum was in fd31cd265138019dcccc9b5fe53043670898bc9f > > If aggressive really is wraparound without difference - i think we need refactor this code, it is difficult have two different flags for same purpose. > > But as far i can see it is possible have aggressive non-wraparound vacuum. One important difference - regular and aggressive regular can be canceled by backend,.wraparound autovacuum can not. (by checking PROC_VACUUM_FOR_WRAPAROUND in src/backend/storage/lmgr/proc.c ) Yes, without checking the code, they should be different. Aggressive is controlled by vacuum_freeze_table_age whereas anti-wrap is controlled by autovacuum_freeze_max_age (but also implies aggressive). Greetings, Andres Freund