Re: Online enabling of checksums
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Robert Haas <robertmhaas@gmail.com>, Magnus Hagander <magnus@hagander.net>, Andrey Borodin <x4mmm@yandex-team.ru>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Michael Banck <michael.banck@credativ.de>, Greg Stark <stark@mit.edu>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-07-31T21:23:44Z
Lists: pgsql-hackers
Hi, On 2018-07-31 23:20:27 +0200, Daniel Gustafsson wrote: > > On 26 Jul 2018, at 19:35, Andres Freund <andres@anarazel.de> wrote: > > On July 26, 2018 10:03:39 AM PDT, Robert Haas <robertmhaas@gmail.com <mailto:robertmhaas@gmail.com>> wrote: > > >> Why can't we do better? > > > > I don't think it's that hard to do better. IIRC I even outlined something before the freeze. If not, o certainly can (sketch: use procsignal based acknowledgment protocol, using a 64 bit integer. Useful for plenty other things). > > Not really arguing for or against, but just to understand the reasoning before > starting hacking. Why do we feel that a restart (intended for safety here) in > this case is a burden on a use-once process? Is it from a usability or > technical point of view? Just want to make sure we are on the same page before > digging in to not hack on this patch in a direction which isn’t what is > requested. Having, at some arbitrary seeming point in the middle of enabling checksums to restart the server makes it harder to use and to schedule. The restart is only needed to fix a relatively small issue, and doesn't save that much code. Greetings, Andres Freund
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