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: Michael Banck <michael.banck@credativ.de>,
Alvaro Herrera <alvherre@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Daniel Gustafsson <daniel@yesql.se>, Robert Haas <robertmhaas@gmail.com>,
Magnus Hagander <magnus@hagander.net>, Andrey Borodin
<x4mmm@yandex-team.ru>, Heikki Linnakangas <hlinnaka@iki.fi>,
Greg Stark <stark@mit.edu>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-08-01T16:25:48Z
Lists: pgsql-hackers
On 08/01/2018 05:58 PM, Andres Freund wrote: > Hi, > > On 2018-08-01 11:15:38 +0200, Tomas Vondra wrote: >> On 08/01/2018 10:40 AM, Michael Banck wrote: >>> If this was one week before feature freeze, I would agree with you >>> that it makes sense to ship it with the restart requirement rather >>> than not shipping it at all. But we're several commitfests away from >>> v12, so making an effort to having this work without a downtime >>> looks like a reasonable requirement to me. >>> >> >> Why would all those pieces had to be committed at once? Why not to >> commit what we have now (with the restart) and then remove the >> restriction in a later commit? > > Sure, if all the pieces existed in various degrees of solidness (with > the earlier pieces committable, but later ones needing work), I'd feel > *much* less concerned about it. > That's not what I meant, sorry for not being clearer. My point was that I see the "without restart" as desirable but optional, and would not mind treating it as a future improvement. > >> In a way, the question is how far can we reasonably push the patch >> author(s) to implement stuff we consider desirable, but he/she/they >> decided it's not worth the time investment at this point. > > We push people to only implement something really consistent all the > time. > Sure, but it's somewhat subjective matter - to me this limitation does not make this particular patch inconsistent. If we can remove it, great. If not, it's still immensely useful improvement. > >> To me, it seems like an immensely useful feature even with the restart, >> and I don't think the restart is a major burden for most systems (it can >> be, if your system has no maintenance windows, or course). > > I think it a problem, my problem is more that I don't think it's really > a solution for the problem. > Sure, if there are issues with this approach, that would make it unacceptable. I'm not sure why would it be an issue for replicas (which is what you mention elsewhere), considering those don't write data and so can't fail to update a checksum? 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