| From: | Tomas Vondra <tomas(at)vondra(dot)me> |
|---|---|
| To: | Michael Banck <mbanck(at)gmx(dot)net> |
| Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Andres Freund <andres(at)anarazel(dot)de>, Bernd Helmle <mailings(at)oopsware(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Changing the state of data checksums in a running cluster |
| Date: | 2026-02-09 22:36:30 |
| Message-ID: | 9541545c-2154-4fb8-9365-b789b3e10bae@vondra.me |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2/9/26 08:52, Michael Banck wrote:
> Hi,
>
> On Fri, Feb 06, 2026 at 12:15:27AM +0100, Tomas Vondra wrote:
>> It's a bit unfortunate we only detect invalid checksums if the failures
>> appear in the server log. I wonder if we could run pg_checksums after
>> the cluster gets shut down in 'fast' mode (we can't do that with
>> immediate shutdowns, of course).
>
> Well, maybe we could do that with immediate shutdowns if we add a
> --force parameter to pg_checksums that is clearly labelled/docmented as
> being dangerous for running instances (but the instance wouldn't run in
> this case). Or something undocumented like
> --debug-force-unclean-controlfile.
>
What would that tell us? Let's say we force running pg_checksums even
after unclean shutdown and it reports some invalid page checksums - then
what? We don't know if that's a bug in the online checksums, or just
(expected) corruption due to immediate shutdown.
regards
--
Tomas Vondra
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2026-02-09 22:37:39 | Re: Changing shared_buffers without restart |
| Previous Message | Andrei Lepikhov | 2026-02-09 22:34:29 | Re: Subquery pull-up increases jointree search space |