From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Sigh, we need an initdb |
Date: | 2014-06-04 23:07:55 |
Message-ID: | 20140604230755.GA387878@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 04, 2014 at 09:16:36PM +0200, Stefan Kaltenbrunner wrote:
> On 06/04/2014 08:56 PM, Joshua D. Drake wrote:
> > On 06/04/2014 11:52 AM, Tom Lane wrote:
> >> I think we could possibly ship 9.4 without fixing this, but it would be
> >> imprudent. Anyone think differently?
> >>
> >> Of course, if we do fix this then the door opens for pushing other
> >> initdb-forcing fixes into 9.4beta2, such as the LOBLKSIZE addition
> >> that I was looking at when I noticed this, or the pg_lsn catalog
> >> additions that were being discussed a couple weeks ago.
> >
> > It certainly seems that if we are going to initdb anyway, let's do it
> > with approved features that got kicked (assuming) only because they
> > would cause an initdb.
>
> agreed there - I dont think the "no initdb rule during BETA" really buys
> us that much these days. If people test our betas at all they do on
> scratch boxes in development/staging, i really doubt that (especially
> given the .0 history we had in the last years) people really move -BETA
> installs to production or expect to do so.
+1. You need a microscope to see the gain from imposing that rule. Even if
people do move beta installs to production, that's just a pg_upgrade away.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-06-04 23:10:16 | Re: [HACKERS] BUG #9652: inet types don't support min/max |
Previous Message | Andres Freund | 2014-06-04 22:59:06 | Re: [HACKERS] BUG #9652: inet types don't support min/max |