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 1x6oz9-000Sdj-0i for pgsql-hackers@arkaria.postgresql.org; Wed, 16 Sep 2026 12:43:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1x6oz8-007Ncx-28 for pgsql-hackers@arkaria.postgresql.org; Wed, 16 Sep 2026 12:43:34 +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.96) (envelope-from ) id 1x6oz8-007Ncp-0c for pgsql-hackers@lists.postgresql.org; Wed, 16 Sep 2026 12:43:34 +0000 Received: from smtp.outgoing.loopia.se ([93.188.3.37]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1x6oz5-00000000NqU-0X5Q for pgsql-hackers@lists.postgresql.org; Wed, 16 Sep 2026 12:43:33 +0000 Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id 022CE789AFB for ; Wed, 16 Sep 2026 14:43:27 +0200 (CEST) Received: from s980.loopia.se (unknown [172.22.191.6]) by s807.loopia.se (Postfix) with ESMTP id E7D9A789C6A; Wed, 16 Sep 2026 14:43:26 +0200 (CEST) Received: from localhost (unknown [172.22.191.5]) by s980.loopia.se (Postfix) with ESMTP id E62C02201636; Wed, 16 Sep 2026 14:43:26 +0200 (CEST) X-Virus-Scanned: amavis at amavis.loopia.se X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=6.2 tests=[ALL_TRUSTED=-1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1] autolearn=disabled Authentication-Results: s474.loopia.se (amavis); dkim=pass (2048-bit key) header.d=yesql.se Received: from s899.loopia.se ([172.22.191.5]) by localhost (s474.loopia.se [172.22.190.14]) (amavis, port 10024) with UTF8LMTP id L6XvGh-4Ibx0; Wed, 16 Sep 2026 14:43:26 +0200 (CEST) X-Loopia-Auth: user X-Loopia-User: daniel@yesql.se X-Loopia-Originating-IP: 89.255.232.236 Received: from smtpclient.apple (customer-89-255-232-236.stosn.net [89.255.232.236]) (Authenticated sender: daniel@yesql.se) by s899.loopia.se (Postfix) with ESMTPSA id 795BE2C8B978; Wed, 16 Sep 2026 14:43:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yesql.se; s=loopiadkim1707475645; t=1789562606; bh=HMciI3XkN+VQbmsGK+HO5K1UuELJWgIVfcnQizFw4tI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=O+g1t0KeFf/l/uYNtscgvqckaC3DCwgGAPI6blClKBKaMtVMa1eI3z6bFlalkBwEp iW0PIgZp5DGnVrxZYNj4ZL23s3UT314d/Ykan5qKpPc3m8NESxLoD4WjzmfukU0+sj 0KfeBD/ZLiw75Ib6yBmunhRDCVr/jaq51eIGcXfHAcRb+oeO/EVqlnucs0I93o7tVO bXcvGEYg7voyIo2ic/B2r3oDxqAbQDixuZ/8lzPFBBs29mvozTCFG7UmKFQiB5ncWw Fy9jN/AYVCxhwAVOmkhF8Na2lwi0bMgv2fTHieULS3l+ehvRrmWh7c91spzEm9+IoJ W+RxaSbbZtiQQ== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.12\)) Subject: Re: pgsql: Revert online data checksum transitions From: Daniel Gustafsson In-Reply-To: Date: Wed, 16 Sep 2026 14:43:15 +0200 Cc: PostgreSQL Hackers , Masao Fujii Content-Transfer-Encoding: quoted-printable Message-Id: References: <1EEAFCFB-15DB-4EC1-BD49-964C799A01B2@yesql.se> To: Aleksander Alekseev X-Mailer: Apple Mail (2.3776.700.51.11.12) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On 16 Sep 2026, at 14:32, Aleksander Alekseev = wrote: >>> We should remove data_page_checksum_version from the = pg_control_checkpoint >>> entry in pg_proc.dat and reduce proargmodes from 20 output columns = to 19? >>=20 >> Ugh, I thought I had tested everything but clearly missed this one. = Will fix immediately when back from lunch. >=20 > I noticed that the revert was applied to REL_19_STABLE but not the > master branch. Just wanted to make sure that's the plan. That's indeed the plan. The remaining issue that a user can, under the = right set of circumstances, get a false positive page verification in an = orphaned file failure during base backup. The warning is harmless for data = integrity, but is non-trivial for the user to resolve since we don't provide any = tools for dealing with orphaned files. Fixing this in master will reduce churn. -- Daniel Gustafsson