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.96) (envelope-from ) id 1vqdCl-00Eng3-39 for pgsql-docs@arkaria.postgresql.org; Thu, 12 Feb 2026 20:22:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vqdCj-00B0tR-33 for pgsql-docs@arkaria.postgresql.org; Thu, 12 Feb 2026 20:22:26 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vqdCj-00B0tJ-26 for pgsql-docs@lists.postgresql.org; Thu, 12 Feb 2026 20:22:26 +0000 Received: from mail-qt1-x835.google.com ([2607:f8b0:4864:20::835]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vqdCh-00000000NFt-3YDX for pgsql-docs@lists.postgresql.org; Thu, 12 Feb 2026 20:22:25 +0000 Received: by mail-qt1-x835.google.com with SMTP id d75a77b69052e-506a321cc53so2797731cf.3 for ; Thu, 12 Feb 2026 12:22:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770927742; cv=none; d=google.com; s=arc-20240605; b=a7khfvS+TxM9PgEQNMrccqKslh+UraIWrpm4eVfeVqY8RFN20D4G5ag2xjeKnC3XNl PzE8LuzXZoEHYccBfLlb4ByFxjuIz/uJTu9FO30H3b874K7OZNCX6luxILmDT6IlOc77 Y4rjYes/OKU/rwLjdjsoXNzZbYOMvDFRVmVFuHVp6jJMdANsK7onAdk0+gzUEe+WK1Ui BySeFXe2hfRGxdeBPcYgjOi2qLKakJP+EgmEljSLkNnYaaWSduJZCnZBAiP1qVITxL3D 34qo5Zx8mE4bOfFgY2QLR1cBiXg/L6YxUyXgl94Ojxr1AQ13LUdB4lMQmd0g3F5BK+nV Ce9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=xIquOlSVle05HpllQ1er2jWX/Z6Tf7MxUyXcPY33rKE=; fh=CrKU+45p1qr81NK6Qh4q1RwUlsXggKHYecB04+qHMgk=; b=GTDdUebVAICNAbBv5HdxHRx/256a9UV7YYXc6HHoMWT5jp1dYnuvSHP4sL+pvan+ao aj34UkQEz0L2emvzTf9/x66bbqGZvibxTMVFL+gJdOtruLppAPOhF6UbT5f379wZsNdd Kh56A+8v5z8FFRy4LYgdmxCnc6foXDlzIMmB0kL9Im5FiwK/0M0o4wAoWz7+NTWB/54V R65wkLDDG2rvPwPgNZASEzsJcCW8z92JmELIEHPIsbJ2VbOMxjLYOeStDsk/yW5wKQ3w I1IpeX54Lsyo/VjGmgHyg9fMLlFCr3loE1jv7R6oEEIK0tlEGSQsFBjfax84I5yDozPO 0zfA==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fittl.com; s=google; t=1770927742; x=1771532542; darn=lists.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=xIquOlSVle05HpllQ1er2jWX/Z6Tf7MxUyXcPY33rKE=; b=VWoeyKuL3nYmkVu9YTdNCr/hWldlEkbRNSwGIi2HyrJZpBQc4OMU7efkiz9tE+geMu Z93jz8QeSj9PdPo4/AkvIVDkVF0Q5TOxY6Wp1iqksPz+7bqxa/50JA0Zk0EylpA/uwQr fZ4ePHi9ua52LVZ/ztpnulESKhVL9lY4VZUm0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770927742; x=1771532542; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=xIquOlSVle05HpllQ1er2jWX/Z6Tf7MxUyXcPY33rKE=; b=afOqRvWisncEbjJWfiz/LAUop4PKTesqODs5n7VhW7/wKc6mz3ukBQLD2laQOayaG9 TOY87lZ8p6pLIdBL30I4VdLnUladWUIUSD9zd4TchxZhhmXgXpWOP42eCciOHxR9dMaN 75/PyjQAL2jNhMiLc8zMGF2b9VSWqMjDjhYpKnA1FW3vH6RR1bwCNsrEp86iEIJ+HXkV oAfduONpqC2Jm7DxqZSzMiByZNQMtXHN6idnnDH0pirpRYpkJ3tzWPYOUtEBZwcCCDFC Rhh7jFCfM8B+dXR+g4G0ND1+0mkCYocZ77vbGzbQq/wI7Vrrk9rUT59MDKutEzhHg3WS +cGQ== X-Forwarded-Encrypted: i=1; AJvYcCXDvVwxCe4ncadw7xbtv4iKELBDbGsS5Yx0ZJnQmq8ESPO7urnz+zUL2oDinrayZoYgtdEo4qihDUGU@lists.postgresql.org X-Gm-Message-State: AOJu0YyPVyTyGRFxNmTprzqGAzXVaMwnXldBAnIDfOvkaUsm8h4SI0X8 +sOK5IApiXq0Sl1m646uMN5z/Cb2aa0Spz9ox/ObyQ0qpEyIBwS8R1CX4bIWk9WbJ0EgtKyFOJj ddJ8DQOthB/Z3tTazxuAVqU3Teuh9eEDH9hEaGami X-Gm-Gg: AZuq6aKprLgl7iGn46JQjOvgaBMffGA5cLBJc5AlbzV5Y25AcJWkaPxZ+V45ZNKzIXj Vq9EmL4t+iLZPg9OBFFGFRCruzZIRuhVHaviJvGe62IQ9oEe2DMJqd+4OwKjwJs6lduYoHRVPss HqB8InmRkFsPgJ8ItYQXduaPTEdhdwC/pBn1tj6ANWTSfBm9bCfqc4HEj/l877QRVsUww7yP9Ao RXGFlCwoxb9FKYH//rfe038R4pJau+EsQpjTbfTeaU39XaEycl45Mz7zMnhmPtRhh5A3jLXRg8w KzZqOvCV9HppSSWTTaCRieFmpIvAfHx0Fhrw3ew= X-Received: by 2002:ac8:5dd3:0:b0:4ff:b21b:218d with SMTP id d75a77b69052e-506a42dd459mr10108841cf.78.1770927741533; Thu, 12 Feb 2026 12:22:21 -0800 (PST) MIME-Version: 1.0 References: <177089689173.797.9982569831633965239@wrigleys.postgresql.org> In-Reply-To: <177089689173.797.9982569831633965239@wrigleys.postgresql.org> From: Lukas Fittl Date: Thu, 12 Feb 2026 12:21:45 -0800 X-Gm-Features: AZwV_QiIMmnpac7lTCS5yhif-7Wd5PGpPqn7xr0krBe806hmwAMyzRgOcDu02Iw Message-ID: Subject: Re: "Disadvantages of increasing autovacuum_freeze_max_age" paragraph to be modified To: divyamodernite@gmail.com, pgsql-docs@lists.postgresql.org Cc: Tom Lane , Heikki Linnakangas 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 Thu, Feb 12, 2026 at 8:52=E2=80=AFAM PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/18/routine-vacuuming.html > Description: > > Hello > > The current doc says (Routine Vacuuming for all available versions) : > > "The sole disadvantage of increasing autovacuum_freeze_max_age (and > vacuum_freeze_table_age along with it) is that the pg_xact and pg_commit_= ts > subdirectories of the database cluster will take more space, because it m= ust > store the commit status and (if track_commit_timestamp is enabled) timest= amp > of all transactions back to the autovacuum_freeze_max_age horizon. The > commit status uses two bits per transaction, so if autovacuum_freeze_max_= age > is set to its maximum allowed value of two billion, pg_xact can be expect= ed > to grow to about half a gigabyte and pg_commit_ts to about 20GB. If this = is > trivial compared to your total database size, setting > autovacuum_freeze_max_age to its maximum allowed value is recommended. > Otherwise, set it depending on what you are willing to allow for pg_xact = and > pg_commit_ts storage. (The default, 200 million transactions, translates = to > about 50MB of pg_xact storage and about 2GB of pg_commit_ts storage.)" > > Based on my experience, the growing size of pg_xact and pg_commit_ts > subdirectories is not the "sole" disadvantage of increasing > autovacuum_freeze_max_age. The higher the value is, the later autovacuum > will be triggered to prevent wraparound. Autovacuum launches workers to d= o > the work primarily for 2 reasons : 1. If the no. for dead tuples is great= er > than the calculated threshold, and 2. If the no. of txids consumed by the > database cluster have reached/surpassed autovacuum_freeze_max_age. If we > increase the autovacuum_freeze_max_age to 2 billion (as recommended above= ), > to trigger on the second condition autovacuum might be too late already. > This is a more important point in my opinion than the one in the docs. I would agree with this understanding. I don't understand why this is worded the way it is today, it seems like bad guidance. To capture as I understand it: One should not set autovacuum_freeze_max_age to two billion because that would effectively make one dependent on the (now luckily existing) failsafe vacuums, instead of doing anti-wraparound vacuums. Looking back at the history, I think this was first worded that way in 48188e1621bb, almost 20 years ago, and whilst the text has changed over the years, the intent seems to come from back then. Adding Tom and Heikki since they were involved in that commit back then, and may recall why the wording was changed that way? > My suggestion would be : > 1. To not recommend setting autovacuum_freeze_max_age to 2 billion, as i= t > contradicts with the paragraph already mentioned in the docs : > "The maximum time that a table can go unvacuumed is two billion transacti= ons > minus the vacuum_freeze_min_age value at the time of the last aggressive > vacuum. If it were to go unvacuumed for longer than that, data loss could > result. To ensure that this does not happen, autovacuum is invoked on any > table that might contain unfrozen rows with XIDs older than the age > specified by the configuration parameter autovacuum_freeze_max_age. (This > will happen even if autovacuum is disabled.)" > > 2. Remove the word "sole", as its not true (already explained above why). +1 to both points. Thanks, Lukas -- Lukas Fittl