From: | Paul Förster <paul(dot)foerster(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: pg_checksums? |
Date: | 2023-10-30 13:14:49 |
Message-ID: | 7E295951-4481-457F-93E6-D8A55D7A15A2@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi Michael,
> On Oct 30, 2023, at 01:56, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> Hm? Page checksums are written when a page is flushed to disk, we
> don't set them for dirty buffers or full-page writes included in WAL,
> so it should be OK to do something like the following:
> - Stop cleanly a standby.
> - Run pg_checksums on the standby to enable them.
> - Restart the standby.
> - Catchup with the latest changes
> - Stop cleanly the primary, letting the shutdown checkpoint be
> replicated to the standby.
> - Promote the standby.
> - Enable checksums on the previous primary.
> - Start the previous primary to be a standby of the node you failed
> over to.
That's exactly the reasoning behind my initial idea and question. Patroni does the switchover job for me including catching up on the latest changes, etc.
Seems that opinions vary. Are there any hard facts?
It turns out that enabling checksums can take quite some time to complete, i.e. downtime for the application which is hard to do in a 24x7 environment.
Cheers
Paul
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Förster | 2023-10-30 13:18:13 | Re: pg_checksums? |
Previous Message | Guillaume Lelarge | 2023-10-30 12:53:50 | Re: xmax not zero? |