| From: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
|---|---|
| To: | "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 19:16:36 |
| Message-ID: | 538F7094.1050108@kaltenbrunner.cc |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
Stefan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2014-06-04 19:21:28 | Re: Sigh, we need an initdb |
| Previous Message | Joshua D. Drake | 2014-06-04 18:56:44 | Re: Sigh, we need an initdb |