I have to say that during beta testing I ALWAYS do an initdb and a reload
just to make sure the pg_dumpall and pg_restore stuff works right. Plus
to make sure problems that might only pop up with a new initdb are found
as well. I probably "burn it to the ground" several times on a single
beta just to test different data sets and I prefer a clean database when
doing that so I'm sure the problems I see are from just that one dataset.
So, Requiring an initdb for every beta wouldn't bother me one bit. To me
you test a beta by migrating to it just like it was a production version,
and that means a new build from the ground up, initdb and all.
On 18 Sep 2002, Neil Conway wrote:
> "Marc G. Fournier" <scrappy@hub.org> writes:
> > On Wed, 18 Sep 2002, Bruce Momjian wrote:
> > > We should get _all_ the known initdb-related issues into the code
> > > before we go beta2 or beta3 is going to require another initdb.
> >
> > Right, and? How many times in the past has it been the last beta in
> > the cycle that forced the initdb? Are you able to guarantee that
> > there won't* be another initdb required if we wait until mid-next
> > week?
>
> I completely agree with Bruce here. Requiring an initdb for every beta
> release significantly reduces the number of people who will be willing
> to try it out -- so initdb's between betas are not disasterous, but
> should be avoided if possible.
>
> Since waiting till next week significantly reduces the chance of an
> initdb for beta3 and has no serious disadvantage that I can see, it
> seems the right decision to me.
>
> Cheers,
>
> Neil
>
>
