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" <[EMAIL PROTECTED]> 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 > > ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
