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 1vMXGM-00CtTK-0n for pgsql-hackers@arkaria.postgresql.org; Fri, 21 Nov 2025 19:57:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vMXGK-009NoG-2d for pgsql-hackers@arkaria.postgresql.org; Fri, 21 Nov 2025 19:57:45 +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 1vMXGK-009No6-1R for pgsql-hackers@lists.postgresql.org; Fri, 21 Nov 2025 19:57:44 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vMXGI-000mLK-2A for pgsql-hackers@lists.postgresql.org; Fri, 21 Nov 2025 19:57:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=momjian.us; s=2025010100; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description; bh=XFyhS+LDEmHtGes6prTXP6JOZLakXvLDgu6JZ6kifAQ=; b=f1Kk3 Zk2xta17fwEap7xWDoa5Mf12bFTNO5XR9HCyOQ121sOtTX9Ny3n7msyOZ8LjDAUf+eIBpiNyu855k evyq3zQhDuqeGosXxZ0UgWbbRFB9XbQWURYqux2XXV0jiSvkPgdNfnyR/VXzB29eml/eUtPw5nT0D c2FW5mfovVUMJdEb7pA06Y+ttbD6PMA+6Njyu5KTuVco4wjf9B6be37A97RknW7l0cd+84qwWxGw8 iU8rK1NlPr7OgV07H0Nnn1AG/tIWC2IT+WScBW7LutBycGHdbmHK2ieHXzkoomO+pqSQu1YFziWwm c7AX/yuj7Q4imDWhZHG9Cy4gPmZ4w==; Received: from bruce by momjian.us with local (Exim 4.98.2) (envelope-from ) id 1vMXGB-0000000GWFz-3KQ7; Fri, 21 Nov 2025 14:57:35 -0500 Date: Fri, 21 Nov 2025 14:57:35 -0500 From: Bruce Momjian To: Tomas Vondra Cc: Andreas Karlsson , Daniel Gustafsson , Bernd Helmle , Michael Paquier , Michael Banck , PostgreSQL Hackers Subject: Re: Changing the state of data checksums in a running cluster Message-ID: References: <3e67160c-3676-4419-b635-1fdb80dc128e@vondra.me> <67726BDA-2F21-4D93-B01F-FA68212ED6F0@yesql.se> <9CA2495B-2D6C-4308-97EF-A12CCCAA753E@yesql.se> <9f381b29-c025-446c-8fa2-8185c5606a4f@proxel.se> <3294448e-53a7-4bc1-9d11-72cd1a340dd9@vondra.me> <51b3fa7b-2cf3-4306-bf1c-001aec711f4f@proxel.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Nov 21, 2025 at 01:17:09PM +0100, Tomas Vondra wrote: > True. Hence the stress testing I've been doing - and indeed, that made > us discover the various issues reported in this thread. > > Still, isn't that similar to error paths in various other patches? Those > also tend to be rarely exercised in practice. I think the right way to > address that is more testing. Of course, there's a difference between > "regular bugs" and "design problems". Some of the issues are more about > the design/architecture not considering something important. > > I don't know if / when this will be ready for commit. Maybe never, who > knows. I prefer going step by step. We know about a couple issues, we > need to figure out what to do about those. Then we can reconsider. > > FWIW I'm not sure the number of people currently enabling checksums on > production databases is a good metric of how important the patch is. > Maybe more people would like to do that, but can't accept the downtime. I think it is a worth-while feature. We would have had it years ago except that people asked for re-start-ability after a crash, and since we don't have restart logic at the relation level, the patch got too complex and was abandoned. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.