On Wed, Oct 19, 2016 at 6:30 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Robert Haas wrote: >> On Mon, Jan 4, 2016 at 10:30 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
