Re: Improve behavior of concurrent TRUNCATE

On 2018-Aug-10, Michael Paquier wrote:

> On Fri, Aug 10, 2018 at 02:03:28PM -0400, Alvaro Herrera wrote:
> > On 2018-Aug-06, Michael Paquier wrote:
> >> Like cbe24a6, perhaps we would not want to back-patch it? Based on the
> >> past history (and the consensus being reached for the REINDEX case would
> >> be to patch only HEAD), I would be actually incline to not back-patch
> >> this stuff and qualify that as an improvement. That's also less work
> >> for me at commit :)
> >
> > I'm not sure I understand your arguments for not back-patching this.
>
> Mainly consistency. Looking at the git history for such cases we have
> not really bothered back-patching fixes and those have been qualified as
> improvements. If we were to close all the holes mentioned in the
> original DOS thread a back-patch to v11 could be thought as acceptable?
> That's where the REINDEX fix has found its way after all, but that was
> way less code churn, and we are post beta 3 for v11...

I was actually thinking in applying to all back-branches, not just pg11,
considering it a fix for a pretty serious bug. But checking the
history, it seems that Robert patched this is 9.2 as new development
(2ad36c4e4, 1489e2f26, cbe24a6dd, 1da5c1195, 74a1d4fe7); holes remained,
but none was patched until 94da2a6a in pg10 -- took some time! And then
nobody cared about the ones you're patching now.

So I withdraw my argumentation, mostly because there's clearly not as
much interest in seeing this fixed as all that.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services