On Wed, Oct 19, 2016 at 6:30 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Robert Haas wrote:
>> On Mon, Jan 4, 2016 at 10:30 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> >> This seems like a might subtle thing to backpatch. If we really want to
>> >> go there, ISTM that the relevant code should stew in an unreleased
>> >> branch for a while, before being backpatched.
>> >
>> > I'm definitely -1 on back-patching such a thing. Put it in HEAD for
>> > awhile. If it survives six months or so then we could discuss it again.
>>
>> I agree with Tom.
>
> Okay, several months have passed with this in the development branch and
> now seems a good time to backpatch this all the way back to 9.4.
>
> Any objections?
Although the code has now been in the tree for six months, it's only
been in a released branch for three weeks, which is something about
which to think.
I guess what's really bothering me is that I don't think this is a bug
fix. It seems like a performance optimization. And I think that we
generally have a policy that we don't back-patch performance
optimizations. Of course, there is some fuzziness because when the
performance gets sufficiently bad, we sometimes decide that it amounts
to a bug, as in 73cc7d3b240e1d46b1996382e5735a820f8bc3f7. Maybe this
case qualifies for similar treatment, but I'm not sure.
Why are you talking about back-patching this to 9.4 rather than all
supported branches?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
