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

Bruce Momjian <bruce@momjian.us>

From: Bruce Momjian <bruce@momjian.us>
To: Tomas Vondra <tomas@vondra.me>
Cc: Andreas Karlsson <andreas@proxel.se>, Daniel Gustafsson <daniel@yesql.se>, Bernd Helmle <mailings@oopsware.de>, Michael Paquier <michael@paquier.xyz>, Michael Banck <mbanck@gmx.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-11-21T19:57:35Z
Lists: pgsql-hackers
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  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.