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 1vpZry-00BQLP-18 for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Feb 2026 22:36:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vpZrx-00CsdE-1D for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Feb 2026 22:36:37 +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 1vpZrw-00Csd6-3D for pgsql-hackers@lists.postgresql.org; Mon, 09 Feb 2026 22:36:36 +0000 Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vpZru-00000001tDE-1Mcg for pgsql-hackers@lists.postgresql.org; Mon, 09 Feb 2026 22:36:36 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 0F9E31F68D; Mon, 9 Feb 2026 22:36:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vondra.me; s=gm1; t=1770676592; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wLHpVHgBmaw5lHOhoJYzXxyRzjN6hV8sfJL/vauuqig=; b=h8owoR+5VNJ386aO/JkFiB+LoxRbfqa6NdDDXgxWN1cMLSAF+LF21Q8x2zF3xtBVJPX/F/ /XJELSM5Qe4bt9o3s8dynaDKnENadUMIreJxJxWoXZCcONL8ENN9dtUFUC24aldHJxs8X5 jfdNVBMmlBRv+Kbgs7Ws9kI/72knZ5cYECHgNBHQDhursV6Hw2VoCq5DAS1+oVz0WXVhbL b1Ojjt16ik6x5EApU0jDN9YUkJYGMFUYjti8nRCj0OXZbmo0aM2ckJt1awbR+sV3J990XL leDkLB6tdkcwKad9VbZHSvD5Fod7IWIj6aUqM6YJg74YxD7BpbAIzs0DqDu/iA== Message-ID: <9541545c-2154-4fb8-9365-b789b3e10bae@vondra.me> Date: Mon, 9 Feb 2026 23:36:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Changing the state of data checksums in a running cluster To: Michael Banck Cc: Daniel Gustafsson , Andres Freund , Bernd Helmle , Michael Paquier , PostgreSQL Hackers References: <3e67160c-3676-4419-b635-1fdb80dc128e@vondra.me> <67726BDA-2F21-4D93-B01F-FA68212ED6F0@yesql.se> <9CA2495B-2D6C-4308-97EF-A12CCCAA753E@yesql.se> <477897AE-1314-4724-9694-0BABC4F4ABDA@yesql.se> <5mv5vtbqj2xm2wmevsi22smyn32jtznva3ya3daih3ixh3onex@s5fyab63xt3c> <2535E72D-5979-4F58-A2D3-2AA4AA335C20@yesql.se> <775fddbc-4dec-413d-89bb-1a8186858ee6@vondra.me> <20260209075210.GB23161@p46.dedyn.io;lightning.p46.dedyn.io> Content-Language: en-US From: Tomas Vondra In-Reply-To: <20260209075210.GB23161@p46.dedyn.io;lightning.p46.dedyn.io> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-GND-Sasl: tomas@vondra.me X-GND-Score: -100 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdduleektddvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepvfhomhgrshcugghonhgurhgruceothhomhgrshesvhhonhgurhgrrdhmvgeqnecuggftrfgrthhtvghrnhepledugeeikefglefhgfffuedvleetteevgefhvdeikeefudduuddvhfevudefhfevnecukfhppeekfedriedurddujedrudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeekfedriedurddujedruddphhgvlhhopegluddtrddufeejrddtrddukegnpdhmrghilhhfrhhomhepthhomhgrshesvhhonhgurhgrrdhmvgdpqhhiugeptdfhlefgfeduhfeikeffpdhmohguvgepshhmthhpohhuthdpnhgspghrtghpthhtohepiedprhgtphhtthhopehmsggrnhgtkhesghhmgidrnhgvthdprhgtphhtthhopegurghnihgvlheshigvshhqlhdrshgvpdhrtghpthhtoheprghnughrvghssegrnhgrrhgriigvlhdruggvpdhrtghpthhtohepmhgrihhlihhnghhssehoohhpshifrghrvgdruggvpdhrtghpthhtohepmhhitghhrggvlhesphgrqhhuihgvrhdrgiihiidprhgtphhtthhopehpghhsqhhlqdhhrggtkhgvr hhssehlihhsthhsrdhpohhsthhgrhgvshhqlhdrohhrgh X-GND-State: clean List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2/9/26 08:52, Michael Banck wrote: > Hi, > > On Fri, Feb 06, 2026 at 12:15:27AM +0100, Tomas Vondra wrote: >> It's a bit unfortunate we only detect invalid checksums if the failures >> appear in the server log. I wonder if we could run pg_checksums after >> the cluster gets shut down in 'fast' mode (we can't do that with >> immediate shutdowns, of course). > > Well, maybe we could do that with immediate shutdowns if we add a > --force parameter to pg_checksums that is clearly labelled/docmented as > being dangerous for running instances (but the instance wouldn't run in > this case). Or something undocumented like > --debug-force-unclean-controlfile. > What would that tell us? Let's say we force running pg_checksums even after unclean shutdown and it reports some invalid page checksums - then what? We don't know if that's a bug in the online checksums, or just (expected) corruption due to immediate shutdown. regards -- Tomas Vondra