Re: Sigh, we need an initdb - Mailing list pgsql-hackers

From David G Johnston
Subject Re: Sigh, we need an initdb
Date
Msg-id 1401934415768-5806137.post@n5.nabble.com
Whole thread Raw
In response to Re: Sigh, we need an initdb  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
Responses Re: Sigh, we need an initdb  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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.

If we are planning on keeping this rule, which it seems like at least a few
people feel is too stringent, maybe we can consider releasing an Alpha
version and communicate the expectation that an initdb will be required to
go from the alpha to beta1.  Then hopefully, but not certainly, no initdb
needed once in the beta phase.  Basically convert beta1 into an alpha with
that single policy/expectation change.

David J.




--
View this message in context: http://postgresql.1045698.n5.nabble.com/Sigh-we-need-an-initdb-tp5806058p5806137.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: slotname vs slot_name
Next
From: Tom Lane
Date:
Subject: Re: Sigh, we need an initdb