Re: Changing the state of data checksums in a running cluster

From: Andres Freund <andres(at)anarazel(dot)de>
To: Andreas Karlsson <andreas(at)proxel(dot)se>
Cc: Tomas Vondra <tomas(at)vondra(dot)me>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Bernd Helmle <mailings(at)oopsware(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, Michael Banck <mbanck(at)gmx(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Changing the state of data checksums in a running cluster
Date: 2025-11-21 20:28:40
Message-ID: mmhed2n6qn7vhae7s6y75emugegtab3w6byrlmpp5sy4dgaovo@fholglopns5w
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2025-11-21 01:44:31 +0100, Andreas Karlsson wrote:
> On 11/20/25 11:34 AM, Tomas Vondra wrote:
> > On 11/19/25 22:03, Andreas Karlsson wrote:
> > > 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.

FWIW, I think this is actually a good feature build the infrastructure for
features (i.e. dynamically reconfiguring the cluster while running) like this,
precisely because it isn't *constantly* used.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2025-11-21 20:47:46 Re: should we have a fast-path planning for OLTP starjoins?
Previous Message Tom Lane 2025-11-21 20:14:15 Re: should we have a fast-path planning for OLTP starjoins?