Re: Online enabling of checksums - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Online enabling of checksums
Date
Msg-id CABUevEyF+4m_-mnYTDbn_SK-yLQTJLOWmnzFa8VuuzBmgFOwhQ@mail.gmail.com
Whole thread Raw
In response to Re: Online enabling of checksums  (Andrey Borodin <x4mmm@yandex-team.ru>)
List pgsql-hackers


On Tue, Mar 20, 2018 at 10:29 AM, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
Hi!

> 19 марта 2018 г., в 11:27, Heikki Linnakangas <hlinnaka@iki.fi> написал(а):
>
> Is there no way to stop the checksum helper once it's started? That seems rather user-unfriendly. I can imagine it being a pretty common mistake to call pg_enable_data_checksums() on a 10 TB cluster, only to realize that you forgot to set the cost limit, and that it's hurting queries too much. At that point, you want to abort.
I've tried to pg_cancel_backend() and it worked.
But only if I cancel "checksum helper launcher" and then "checksum helper worker". If I cancel helper first - it spawns new.

Magnus, Daniel, is it safe to cancel worker or launcher?

It should be perfectly safe yes. However, it's not very user friendly, because you have to go around and cancel both (meaning you actually have to cancel them in the right order, or a new one will be launched).

Daniel is working on a proper way to stop things.

 

BTW, I have some questions on pg_verify_chechsums.
It does not check catalog version. It it true that it will work for any?

Yes. The actual page format for checksums has not changed since checksums were introduced. I have successfully used it to validate checksums on v10 clusters for example.

 
Also, pg_verify_chechsums will stop on short reads. But we do not stop on wrong checksum, may be we should not stop on short reads either?


These are very different scenarios though -- it's explicitly intended to validate checksums, and short reads is a different issue. I prefer the way it does it now, but I am not strongly locked into that position and can be convinced otherwise :)

--

pgsql-hackers by date:

Previous
From: Rushabh Lathia
Date:
Subject: Re: INOUT parameters in procedures
Next
From: Andrew Gierth
Date:
Subject: Re: PostgreSQL 10: Segmentation fault when using GROUPING SETS with all unsortable columns