| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, pgsql-core <pgsql-core(at)postgresql(dot)org> |
| Subject: | Re: [CORE] postpone next week's release |
| Date: | 2015-05-31 16:24:49 |
| Message-ID: | 20150531162449.GA23118@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, May 31, 2015 at 11:55:44AM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> >> FYI, I realize that one additional thing that has discouraged code
> >> reorganization is the additional backpatch overhead. I think we now
> >> need to accept that our reorganization-adverse approach might have cost
> >> us some reliability, and that reorganization is going to add work to
> >> backpatching.
>
> > Actually, code reorganization in HEAD might cause backpatching to be
> > more buggy, reducing reliability --- obviously we need to have a
> > discussion about that.
>
> Commit 6b700301c36e380eb4972ab72c0e914cae60f9fd is a recent real example.
> Not that that should dissuade us from ever doing any reorganizations,
> but it's foolish to discount back-patching costs.
Yep.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2015-05-31 16:49:59 | Re: Join Filter vs. Index Cond (performance regression 9.1->9.2+/HEAD) |
| Previous Message | David Steele | 2015-05-31 16:09:16 | Re: [CORE] postpone next week's release |