Re: Online enabling of checksums

Tomas Vondra <tomas.vondra@2ndquadrant.com>

From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>, Magnus Hagander <magnus@hagander.net>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Daniel Gustafsson <daniel@yesql.se>
Date: 2018-02-24T02:34:01Z
Lists: pgsql-hackers

On 02/24/2018 03:11 AM, Andres Freund wrote:
> Hi,
> 
> On 2018-02-24 03:07:28 +0100, Tomas Vondra wrote:
>> I agree having to restart the whole operation after a crash is not
>> ideal, but I don't see how adding a flag actually solves it. The problem
>> is the large databases often store most of the data (>80%) in one or two
>> central tables (think fact tables in star schema, etc.). So if you
>> crash, it's likely half-way while processing this table, so the whole
>> table would still have relchecksums=false and would have to be processed
>> from scratch.
> 
> I don't think it's quite as large a problem as you make it out to
> be. Even in those cases you'll usually have indexes, toast tables and so
> forth.
> 

Hmmm, right. I've been focused on tables and kinda forgot that the other
objects need to be transformed too ... :-/

>> But perhaps you meant something like "position" instead of just a simple
>> true/false flag?
> 
> I think that'd incur a much larger complexity cost.
> 

Yep, that was part of the point that I was getting to - that actually
addressing the issue would be more expensive than simple flags. But as
you pointed out, that was not quite ... well thought through.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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.