Hi! So, what should we do with the PG18 open item? We (the RMT team) would like to know if we shall keep the checksums enabled by default, and if there's something that still needs to be done for PG18.
We don't have a strong opinion either way, but there doesn't seem to be much happening on this thread. So if someone feels we should rethink and disable the checksums by default for PG18, he/she needs to articulate that proposal. The sooner the better. The commit that flipped the default (04bec894a04c) is from Peter Eisentraut, and while that doesn't make him solely responsible for the change, we think it'd be good to know his opinion on this. But it seems more like a change requiring a wider consensus, and I'm aware e.g. Andres expressed some doubts about enabling checksums [2]. In any case, the default is "on" at the moment, and unless someone advocates for changing it soon, that's what we'll get in PG19. My personal opinion is keeping checksums enabled by default seems OK. It's not perfect, but it does seem like a reasonable trade off to me. I'm aware of three issues people mention as arguments against checksums: 1) performance It does have performance impact, and it'll always have performance impact. Even if we make the checksums infinitely fast, we'll still have to do more writes etc. There's no way around that. And I think that's fine/acceptable. I'm sure there are cases of checksums causing unnecessary regressions. Commit e6eed40e44419 [3] is a good example of such case. I don't know how many such cases exist, but I don't think it's very many. We need to find and fix those cases - we just never did, because checksums were off by default. In any case, the cost seems reasonable to me. 2) upgrade user experience I think this was the other concern in this thread - that it'll be hard for users to do upgrades (using pg_upgrade). But I believe this should have been sorted out now, am I right? 3) checksums user experience I'm aware dealing with checksums can be rough. That is, we don't have great tooling to verify checksums on-line, and once you get a checksum error, you're mostly on your own. Or rather, the solution is to fail over to a standby or restore from a backup. Which is fine, and I don't have a great idea/proposal what else to do. If we require improving this before enabling checksums by default, someone probably needs to describe what improvements are needed to make that happen. regards [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=04bec894a04cb0d32533f1522ab81b7016141ff1 [2] https://www.postgresql.org/message-id/brdaw5wke274lubirrl4v2k4qdacylvgwwqztifn7m27pkth3s%40rh7wie47pfcp [3] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=e6eed40e44419e3268d01fe0d2daec08a7df68f7 -- Tomas Vondra
