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.
