Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tcVsq-000dO6-Ag for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Jan 2025 20:39:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tcVso-00EVBA-M8 for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Jan 2025 20:38:58 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tcVso-00EVB0-Cl for pgsql-hackers@lists.postgresql.org; Mon, 27 Jan 2025 20:38:58 +0000 Received: from mail-ej1-x62a.google.com ([2a00:1450:4864:20::62a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tcVsh-001p1Q-1x for pgsql-hackers@postgresql.org; Mon, 27 Jan 2025 20:38:57 +0000 Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-aaf6b1a5f2bso1202834866b.1 for ; Mon, 27 Jan 2025 12:38:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738010330; x=1738615130; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=E0Xy+8LQdZ1fVUCopuHHgSwhlris4uthGseDWvcAEEk=; b=f/b0dIv9WrFfIHhEoM1Gy1S4ByoN6dJM1N2t9yoLQJhAN7+IYYxaxPkZmkty4scDCA Oe4RBGGbdCFyy3nHop5lvkXXMgUqLm+AthsMnjnln86rmplD73sf7XoeisXxLnZv/G5e f2YxHcMUAMfzNLxrKTPMj0j+lumBDvncIEvoSSxl5/5UtRoTxWNkmg9svvYjng+xV1Zb IkXtC9+8o3Trwi3D7exRNi6lIDvjU/C6z/fZBtZubqjtS8Vq990/KVlU7dvjXx+2Qjwh /QkIst7oi/45SNzZGHsmImwTNqtPjr665rvtsU9mDyl0roX/cX8Cl939JTO0DuZ4/hNR 40xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738010330; x=1738615130; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=E0Xy+8LQdZ1fVUCopuHHgSwhlris4uthGseDWvcAEEk=; b=g8vlz4faVOaPyFUXOq7Pfhl6D8eyqkyAerSjbV3blbGdGvMHbAEn1TK9fggUKw0LSu SyKfD5PScmDDD7YCKvEXvQmHiq9SgnDDAcr6CNt3/UqGRay0NSXIV0vwvVASymvFjFe4 Gr4c4HsSIhrW202lOmjslj9WHXaalVYCEOXrNPnxFCZJGrrcu6QXbWghWuRN+q3hRP7a HRFlUD+Yhuyd5EDeDStMn5O7qHm/bAlUyvSzT6HfBH3gpj/w7tZO3fp9Gnei2RZVjyaw dTk/YULGo2P7F5jQFCycTG1uW6A0ivwiYkj966gd11ZBTr49wWSA4dgd5BaI6W0I5IC4 7pvQ== X-Forwarded-Encrypted: i=1; AJvYcCU20Ujo767T5Mj+qK9KwNuftc1lMkNwr7quNf+Wr+ssF2+MJ7UGDhPTd5Rgwj71oF1tt/Gh5xJ3T5JV0XNm@postgresql.org X-Gm-Message-State: AOJu0YzQgrLAznfiLuXsqjRDlZCn4tlVJleVp1CWuOuPOhlnKdTJmLNP Q6BBAJzAfGotBD87E9P8CbD4+A5TIEQkDCAegWLAftUXc5z9qt3JdLDnJxD0R80XmxacB5fw7m0 s4sQpJ6uy+ORMY/0OEek//hvIa5Y= X-Gm-Gg: ASbGncvn9klXlP/+4MWfFzA6uEfZ1aLYln+tTBq6X+gUXDvZBN+hCRut4WWCpi5Rpz8 GqFMiobTqTbj8mi6eOFgrYMjXC+UhaFjEutJLjbUnTTRRINi2JPDyfMWBlFmVOA== X-Google-Smtp-Source: AGHT+IHsSjhEpI4XdB+AzU2SG5DPlUT8D0qZPa5xJQvGZdrEwq53cbaDz7oc/juTw+h5ME09nMZz2pEHJZO8n3z/XQc= X-Received: by 2002:a17:907:a2c8:b0:aae:f029:c2ec with SMTP id a640c23a62f3a-ab6bbac06d2mr61726666b.12.1738010330224; Mon, 27 Jan 2025 12:38:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Robert Haas Date: Mon, 27 Jan 2025 15:38:39 -0500 X-Gm-Features: AWEUYZns4ic3LI56g9DRXC4CCXT7sIpCMhpygXpti0NWeEj8cbZ6f2jXZKuh5XU Message-ID: Subject: Re: Disabling vacuum truncate for autovacuum To: Laurenz Albe Cc: Gurjeet Singh , Postgres Hackers , Will Storey Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Jan 27, 2025 at 4:55=E2=80=AFAM Laurenz Albe wrote: > My suggestion for the parameter name is "autovacuum_disable_truncate". Then it would have a different name than the reloption, and the opposite sense. In most cases, we've been able to keep those matching -- autovacuum vs. autovacuum_enabled being, I believe, the only current mismatch. Also, how sure are we that turning this off globally is a solid idea? Off-hand, it doesn't sound that bad: there are probably situations in which autovacuum never truncates anything anyway just because the tail blocks of the relations always contain at least 1 tuple. But we should be careful not to add a setting that is far more likely to get people into trouble than to get them out of it. It would be good to hear what other people think about the risk vs. reward tradeoff in this case. --=20 Robert Haas EDB: http://www.enterprisedb.com