From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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] Restore-reliability mode |
Date: | 2015-06-07 14:10:39 |
Message-ID: | 846697098.6562437.1433686239404.JavaMail.yahoo@mail.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
> On 06/06/2015 07:14 PM, Peter Geoghegan wrote:
>> On Sat, Jun 6, 2015 at 7:07 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> Perhaps we're honoring this more in the breech than in the
>>> observance, but I'm not making up what Tom has said about this:
>>>
>>> http://www.postgresql.org/message-id/27310.1251410965@sss.pgh.pa.us
That's 9.0 release discussion:
| I think that the traditional criterion is that we don't release beta1
| as long as there are any known issues that might force an initdb.
| We were successful in avoiding a post-beta initdb this time, although
| IIRC the majority of release cycles have had one --- so maybe you
| could argue that that's not so important. It would certainly be
| less important if we had working pg_migrator functionality to ease
| the pain of going from beta to final.
>>> http://www.postgresql.org/message-id/19174.1299782543@sss.pgh.pa.us
That's 9.1 release discussion:
| Historically we've declared it beta once we think we are done with
| initdb-forcing problems.
| In any case, the existence of pg_upgrade means that "might we need
| another initdb?" is not as strong a consideration as it once was, so
| I'm not sure if we should still use that as a criterion. I don't know
| quite what "ready for beta" should mean otherwise, though.
>>> http://www.postgresql.org/message-id/3413.1301154369@sss.pgh.pa.us
Also 9.1, it is listed as one criterion:
| * No open issues that are expected to result in a catversion bump.
| (With pg_upgrade, this is not as critical as it used to be, but
| I still think catalog stability is a good indicator of a release's
| maturity)
>>> http://www.postgresql.org/message-id/3261.1401915832@sss.pgh.pa.us
Here we jump to 9.4 discussion:
| > Agreed. Additionally I also agree with Stefan that the price of a initdb
| > during beta isn't that high these days.
|
| Yeah, if nothing else it gives testers another opportunity to exercise
| pg_upgrade ;-). The policy about post-beta1 initdb is "avoid if
| practical", not "avoid at all costs".
So I think these examples show that the policy has shifted from a
pretty strong requirement to "it's probably nice if" status, with
some benefits seen in pg_upgrade testing to actually having a bump.
>> Of course, not doing a catversion bump after beta1 doesn't necessarily
>> have much value in and of itself. *Promising* to not do a catversion
>> bump, and then usually keeping that promise definitely has a certain
>> value, but clearly we are incapable of that.
As someone who was able to bring up a new production application on
8.2 because it was all redundant data and not yet mission-critical,
I appreciate that in very rate circumstances that combination could
have benefit. But really, how often are people in that position?
> It seems to me that a cat bump during Alpha or Beta should be absolutely
> fine and reservedly fine respectively. Where we should absolutely not
> cat bump unless there is absolutely no other choice is during and RC.
+1 on all of that. And for a while now we've been talking about an
alpha test release, right?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2015-06-07 14:53:12 | Re: checkpointer continuous flushing |
Previous Message | Tomas Vondra | 2015-06-07 13:58:46 | Re: [Proposal] More Vacuum Statistics |