Re: Online enabling of checksums - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Online enabling of checksums
Date
Msg-id 20180731213051.q6hodk5lpcvshk37@alap3.anarazel.de
Whole thread Raw
In response to Re: Online enabling of checksums  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2018-07-31 17:28:41 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2018-07-31 23:20:27 +0200, Daniel Gustafsson wrote:
> >> 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.
> 
> Without taking a position on the merits ... I don't see how you can
> claim "it doesn't save that much code" when we don't have a patch to
> compare to that doesn't require the restart.  Maybe it will turn out
> not to be much code, but we don't know that now.

IIRC I outlined a solution around the feature freeze, and I've since
offered to go into further depth if needed. And I'd pointed out the
issue at hand. So while I'd obviously not want to predict a specific
linecount, I'm fairly sure I have a reasonable guesstimate about the
complexity.

- Andres


pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: [HACKERS] Cached plans and statement generalization
Next
From: Andrew Dunstan
Date:
Subject: commitfest 2018-07