Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Jan 30, 2012 at 4:13 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> On Mon, Jan 30, 2012 at 12:30 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I see this was only applied to HEAD. Wouldn't back-patching be in
>>> order? The problem is in 9.1 as well, no?
>> Yes, it is. I prefer to give a little time before backpatching to
>> avoid mistakes (of my own making), especially since we're busy enough
>> not to want to divert energy to other releases right now. The patch
>> will make it in before next minor release.
> If it's going to go in before the next minor release, there's no real
> value in holding off, is there?
It seems like a strange approach to me as well. The longer you wait,
the more the patch details will have faded from your mind, increasing
the chance that you'll mess up any necessary cross-branch adjustments.
I also consider the possibility to be non-zero that it won't get done
at all before the next release.
Another aspect of this is that when the same-or-almost-the-same
patch is applied to multiple branches, it's a *lot* easier for future
archeology in the commit logs if the patch goes into all the affected
branches at the same time (and with the same commit message, please).
Lastly, one of the main reasons for wanting this particular bug fixed
(since after all it's just an Assert failure in the end) is to not have
transient buildfarm failures from it. Those failures are still
happening, in 9.1 if not HEAD, and still distracting attention from
more significant issues.
regards, tom lane
In response to
pgsql-committers by date
|Next:||From: Andrew Dunstan||Date: 2012-01-30 16:24:04|
|Subject: Re: pgsql: Resolve timing issue with logging locks for
|Previous:||From: Heikki Linnakangas||Date: 2012-01-30 14:55:07|
|Subject: pgsql: Make group commit more effective.|