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 1w9lOq-001iyT-1k for pgsql-committers@arkaria.postgresql.org; Mon, 06 Apr 2026 14:58:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w9lOp-009aVQ-0B for pgsql-committers@arkaria.postgresql.org; Mon, 06 Apr 2026 14:57:59 +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 1w9lOo-009aVH-2e for pgsql-committers@lists.postgresql.org; Mon, 06 Apr 2026 14:57:59 +0000 Received: from meldrar.postgresql.org ([2a02:c0:301:0:ffff::31]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w9lOn-00000000rxQ-0KUE for pgsql-committers@lists.postgresql.org; Mon, 06 Apr 2026 14:57:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description; bh=NRDbn8N9Tz/rgDz2pgpDYim19Z9j7P2oZrXALGwRSOU=; b=bTcYzdHqtC4JAcvQlAP3JpxGnK I6Q/QvSradK7fP+o7pBdi3AOT3gjlQJMqmyPxFthwp0xyTIXfB5DGg116YcDQngDKUWPSkzvbA5v0 iiNC5epeKS6PyZXm0WecHqWKlZga7rCXCfTZVnSGP6qSSvH6QKxBOliZBCExykEQuXAyTq1U88aS0 +LQFgDf2ftoqfE4m2IOQNuMR1At67TmiO1duLSvwSf5fOZ5VrIQlZiFZOGpcmYrSWSwzyC++DmE6r GIblY/3qX3mbom4V4rhWmLlzb+cawG94PJXGjBpRGdRZey3CciIZK8E8nY57pCnI5K/OGxhaCn5MI L0ZU6aDA==; Received: from customer-89-255-232-236.stosn.net ([89.255.232.236] helo=smtpclient.apple) by meldrar.postgresql.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w9lOk-00268J-0x; Mon, 06 Apr 2026 14:57:56 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.2\)) Subject: Re: pgsql: Online enabling and disabling of data checksums From: Daniel Gustafsson In-Reply-To: Date: Mon, 6 Apr 2026 16:57:43 +0200 Cc: pgsql-committers@lists.postgresql.org Content-Transfer-Encoding: quoted-printable Message-Id: <97C12A9C-D34F-42BA-936A-32C4E444B500@postgresql.org> References: To: Aleksander Alekseev X-Mailer: Apple Mail (2.3776.700.51.11.2) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On 6 Apr 2026, at 16:39, Aleksander Alekseev = wrote: >=20 > Hi Daniel, >=20 >> Online enabling and disabling of data checksums >>=20 >> [...] >=20 > I noticed a little mistake: Thanks for looking! > ``` > /* > * Await state transition to "on" in all backends. When done we know = that > * data data checksums are both written and verified in all backends. > */ > ``` >=20 > The word "data" is repeated twice. Ugh. > Also there are inconsistencies in the way > XLogCtlData->data_checksum_version, > ControlFileData->data_checksum_version and certain variables are > assigned. Sometimes a hardcoded 0 is used and sometimes > PG_DATA_CHECKSUM_OFF. I suggest using values of the enum > ChecksumStateType for readability / consistency. PG_DATA_CHECKSUM_OFF didn't exist until quite late in the lifetime of = the patch, and clearly not all uses of 0 were ported over. > Here are corresponding patches. I will take another look later today when I have more time, and commit = them. -- Daniel Gustafsson