Re: Offline enabling/disabling of data checksums

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Michael Banck <michael(dot)banck(at)credativ(dot)de>, Postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Offline enabling/disabling of data checksums
Date: 2018-12-27 11:26:26
Message-ID: alpine.DEB.2.21.1812271206340.32444@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


>> For enable/disable, while the command is running, it should mark the
>> cluster as opened to prevent an unwanted database start. I do not see
>> where this is done.
>>
>> You have pretty much the same class of problems if you attempt to
>> start a cluster on which pg_rewind or the existing pg_verify_checksums
>> is run after these have scanned the control file to make sure that
>> they work on a cleanly-stopped instance. [...]
>
> I think it comes down to what the outcome is. If we're going to end up with
> a corrupt database (e.g. one where checksums aren't set everywhere but they
> are marked as such in pg_control) then it's not acceptable. If the only
> outcome is the tool gives an error that's not an error and if re-run it's
> fine, then it's a different story.

ISTM that such an outcome is indeed a risk, as a starting postgres could
update already checksummed pages without putting a checksum. It could be
even worse, although with a (very) low probability, with updates
overwritten on a race condition between the processes. In any case, no
error would be reported before much later, with invalid checksums or
inconsistent data, or undetected forgotten committed data.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2018-12-27 11:28:19 Re: PostgreSQL partition tables use more private memory
Previous Message Amit Langote 2018-12-27 11:25:38 Re: speeding up planning with partitions