From: Kevin Grittner <kgrittn@ymail.com>
To: Joshua D. Drake <jd@commandprompt.com>
To: Peter Geoghegan <pg@heroku.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: Noah Misch <noah@leadboat.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Magnus Hagander <magnus@hagander.net>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Cc: pgsql-core <pgsql-core@postgresql.org>
Subject: Re: [CORE] Restore-reliability mode
Date: Sun, 7 Jun 2015 14:10:39 +0000 (UTC)
Message-ID: <846697098.6562437.1433686239404.JavaMail.yahoo@mail.yahoo.com> (raw)
In-Reply-To: <5573B34F.1090007@commandprompt.com>
References: <5573B34F.1090007@commandprompt.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Joshua D. Drake <jd@commandprompt.com> wrote:
> On 06/06/2015 07:14 PM, Peter Geoghegan wrote:
>> On Sat, Jun 6, 2015 at 7:07 PM, Robert Haas <robertmhaas@gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: kgrittn@ymail.com, jd@commandprompt.com, pg@heroku.com, robertmhaas@gmail.com, simon@2ndquadrant.com, josh@agliodbs.com, noah@leadboat.com, bruce@momjian.us, andres@anarazel.de, tgl@sss.pgh.pa.us, sfrost@snowman.net, magnus@hagander.net, pgsql-core@postgresql.org
Subject: Re: [CORE] Restore-reliability mode
In-Reply-To: <846697098.6562437.1433686239404.JavaMail.yahoo@mail.yahoo.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox