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
-
Online enabling and disabling of data checksums
- f19c0eccae96 19 (unreleased) landed
-
Deactive flapping checksum isolation tests.
- bf75fe47e444 11.0 landed
-
Add support for coordinating record typmods among parallel workers.
- cc5f81366c36 11.0 cited