Message-ID: <db3a8b5d-e7d3-49e8-bec4-12cfd8b2151d@vondra.me>
Date: Fri, 21 Nov 2025 13:17:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Changing the state of data checksums in a running cluster
To: Andreas Karlsson <andreas@proxel.se>, Daniel Gustafsson <daniel@yesql.se>
Cc: Bernd Helmle <mailings@oopsware.de>, Michael Paquier
 <michael@paquier.xyz>, Michael Banck <mbanck@gmx.net>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: <8B317721-1CB7-4F82-B4DA-6B15AB1725D1@yesql.se>
 <2CD83EC2-C971-4440-89F7-BCBAE375F908@yesql.se>
 <830e4296-dbb7-4b5c-be51-64732591f6c8@vondra.me>
 <17C1D2E0-C12D-40E2-B4B8-B9CCECA45A88@yesql.se>
 <47d946a3-c1c7-421d-a2b1-6a51cc329e6c@vondra.me>
 <02DCCE05-537F-4BDE-9C0B-D4935021BBBF@yesql.se>
 <0e6ce93e-57e4-43ed-b410-66876c125ffb@vondra.me>
 <7357A519-3391-4F07-BC69-5C9C2B120792@yesql.se>
 <25c734d1-18bb-4167-bb31-9afa736ea886@vondra.me>
 <dfe57980-f594-46c5-af39-852ff30d34fa@vondra.me>
 <ab76670d-3e2c-4af4-9e29-ffaec54a370d@vondra.me>
 <d9ea8a27-ed46-476f-8a6e-600147b13ff2@vondra.me>
 <3e67160c-3676-4419-b635-1fdb80dc128e@vondra.me>
 <67726BDA-2F21-4D93-B01F-FA68212ED6F0@yesql.se>
 <9CA2495B-2D6C-4308-97EF-A12CCCAA753E@yesql.se>
 <c33d8d86-47ad-4cee-9860-26b324d7306b@vondra.me>
 <f8dbad9d-95c0-42ad-88f2-95ae8e6aa251@vondra.me>
 <9f381b29-c025-446c-8fa2-8185c5606a4f@proxel.se>
 <3294448e-53a7-4bc1-9d11-72cd1a340dd9@vondra.me>
 <51b3fa7b-2cf3-4306-bf1c-001aec711f4f@proxel.se>
Content-Language: en-US
From: Tomas Vondra <tomas@vondra.me>
In-Reply-To: <51b3fa7b-2cf3-4306-bf1c-001aec711f4f@proxel.se>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/db3a8b5d-e7d3-49e8-bec4-12cfd8b2151d%40vondra.me>
Precedence: bulk


On 11/21/25 01:44, Andreas Karlsson wrote:
> On 11/20/25 11:34 AM, Tomas Vondra wrote:
>> On 11/19/25 22:03, Andreas Karlsson wrote:
>>> Hi,
>>>
>>> I have been following these discussions but not read the patch in
>>> detail.
>>>
>>> This patch makes me worried especially with the new issues recently
>>> uncovered. This was already a quite big patch and to fix these issues it
>>> will likely have to become even bigger and given how this would become a
>>> very rarely stressed code paths I wonder if we can actually ever become
>>> confident that the patch works in all edge cases.
>>>
>>> Something like this need to be easy to understand for us to have any
>>> hope at all to be comfortable in the correctness. Can we actually do
>>> that?
>>>
>>
>> How's this different from any other complex patch? We get more familiar
>> with the problem during review, identify issues, improve the patch to
>> address them. And then again and again.
> 
> The difference I see is in how rarely anyone actually switches checksum
> state in a production database, especially now that we enabled them by
> default. A complex and rarely stressed code path is a minefield.
> 

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.

regards

-- 
Tomas Vondra