Re: Online enabling of checksums

Daniel Gustafsson <daniel@yesql.se>

From: Daniel Gustafsson <daniel@yesql.se>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Magnus Hagander <magnus@hagander.net>, Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-02-26T02:17:31Z
Lists: pgsql-hackers
> On 26 Feb 2018, at 05:48, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
> On 02/24/2018 10:45 PM, Magnus Hagander wrote:
>> Is it really that invisible? Given how much we argue over adding
>> single counters to the stats system, I'm not sure it's quite that
>> low.
> 
> I'm a bit unsure where would the flags be stored - I initially assumed
> pg_database/pg_class, but now I see mentions of the stats system.
> 
> But I wonder why should this be stored in a catalog at all? The info is
> only needed by the bgworker(s), so they could easily flush the current
> status to a file every now and then and fsync it. Then after restart, if
> you find a valid file, use it to resume from the last OK position. If
> not, start from scratch.

Since this allows checksums to be turned off as well, storing a flag in the
catalog would mean a issuing a fairly wide update in that case to switch it to
False, which might not be ideal.  Not that I expect (hope) turning checksums
off on a cluster will be a common operation, but thats a fairly large side
effect of doing so.

cheers ./daniel

Commits

  1. Online enabling and disabling of data checksums

  2. Deactive flapping checksum isolation tests.

  3. Add support for coordinating record typmods among parallel workers.