On Mon, Mar 30, 2020 at 11:37:57PM -0700, Andres Freund wrote:
> On 2020-03-30 23:28:54 -0700, Noah Misch wrote:
> > On Mon, Mar 30, 2020 at 04:43:00PM +0900, Michael Paquier wrote:
> > > On Sun, Mar 29, 2020 at 09:41:01PM -0700, Noah Misch wrote:
> > > > I think attached v41nm is ready for commit. Would anyone like to vote against
> > > > back-patching this? It's hard to justify lack of back-patch for a data-loss
> > > > bug, but this is atypically invasive. (I'm repeating the question, since some
> > > > folks missed my 2020-02-18 question.) Otherwise, I'll push this on Saturday.
> > >
> > > The invasiveness of the patch is a concern. Have you considered a
> > > different strategy? For example, we are soon going to be in beta for
> > > 13, so you could consider committing the patch only on HEAD first.
> > > If there are issues to take care of, you can then leverage the beta
> > > testing to address any issues found. Finally, once some dust has
> > > settled on the concept and we have gained enough confidence, we could
> > > consider a back-patch.
> >
> > No. Does anyone favor this proposal more than back-patching normally?
>
> I have not reviewed the patch, so I don't have a good feeling for its
> riskiness. But it does sound fairly invasive. Given that we've lived
> with this issue for many years by now, and that the rate of incidents
> seems to have been fairly low, I think living with the issue for a bit
> longer to gain confidence might be a good choice. But I'd not push back
> if you, being much more informed, think the risk/reward balance favors
> immediate backpatching.
I've translated the non-vote comments into estimated votes of -0.3, -0.6,
-0.4, +0.5, and -0.3. Hence, I revoke the plan to back-patch.
