From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, "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-29 19:53:44 |
Message-ID: | 20150529195344.GM26667@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Magnus Hagander (magnus(at)hagander(dot)net) wrote:
> On Fri, May 29, 2015 at 9:46 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> > > Magnus Hagander <magnus(at)hagander(dot)net> writes:
> > > > On Fri, May 29, 2015 at 9:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > > >> I think there's no way that we wait more than one additional week to
> > push
> > > >> the fsync fix. So the problem is not with scheduling the update
> > releases,
> > > >> it's with whether we can also fit in a 9.5 beta release before PGCon.
> > >
> > > > I think 9.5 beta has to stand back. The question is what we do with the
> > > > potentially two minor releases. Then we can slot in the beta whenever.
> > >
> > > > If we do the minor as currently planned, can we do another one the week
> > > > after to deal with the multixact issues? (scheduling wise we're going
> > to
> > > > have to do one the week after *regardless*, the question is if we can
> > make
> > > > two different ones, or if we need to fold them into one)
> > >
> > > I suppose we could, but it doubles the amount of release gruntwork
> > > involved, and it doesn't exactly make us look good to our users either.
> >
> > Agreed. Makes it look like we can't manage to figure out our bugs and
> > put fixes for them together in sensible releases..
> >
>
> The flipside of that is that we have a bug fix that's preventing peoples
> databases from starting, and we're the intentionally delaying the shipment
> of it. Though i guess a mitigating fact there is that it is very easy to
> manually recover from that. But it's painful if your db server restarts
> awhen you're not around...
And we have *another* fix for a *data corruption* bug which is coming in
the following *week*.
Yes, I think delaying a week to get both in is better than putting out a
fix for one bug when we *know* there's a data corruption bug sitting in
that code, and we're putting out a fix for it the following week.
If we were talking about a month-long delay, that'd be one thing, but
that isn't the impression I've got about what we're talking about.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2015-05-29 19:56:09 | Re: [CORE] postpone next week's release |
Previous Message | Bruce Momjian | 2015-05-29 19:49:53 | Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1 |