> On 8 Aug 2024, at 12:11, Peter Eisentraut <peter@eisentraut.org> wrote:
> My understanding was that the reason for some hesitation about adopting data checksums was the performance impact.
Notthe checksumming itself, but the overhead from hint bit logging. The last time I looked into that, you could get
performanceimpacts on the order of 5% tps. Maybe that's acceptable, and you of course can turn it off if you want the
extraperformance. But I think this should be discussed in this thread.
That's been my experience as well, the overhead of the checksumming is
negligible but the overhead in WAL can be (having hint bits WAL logged does
carry other benefits as well to be fair).
> I think we need to think through the upgrade experience a bit more.
+1
> Unfortunately, pg_checksums hasn't gotten to the point that we were perhaps once hoping for that you could enable
checksumson a live system.
I don't recall there being any work done (or plans for) using pg_checksums on a
live system. Anyone interested in enabling checksums on a live cluster can
however review the patch for that in:
https://postgr.es/m/E07A611B-9CF3-4FDB-8CE8-A221E39040EC@yesql.se
> I'm thinking pg_upgrade could have a mode where it adds the checksum during the upgrade as it copies the files
(essentiallya subset of pg_checksums). I think that would be useful for that middle tier of users who just want a good
defaultexperience.
As a side-note, I implemented this in pg_upgrade at Greenplum (IIRC it was
submitted to -hackers at the time as well) and it worked well with not a lot of
code.
--
Daniel Gustafsson
