Re: Sigh, we need an initdb

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Sigh, we need an initdb
Date: 2014-06-04 21:03:52
Message-ID: 3261.1401915832@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2014-06-04 14:52:35 -0400, Tom Lane wrote:
>> I think we could possibly ship 9.4 without fixing this, but it would be
>> imprudent. Anyone think differently?

> Agreed. Additionally I also agree with Stefan that the price of a initdb
> during beta isn't that high these days.

Yeah, if nothing else it gives testers another opportunity to exercise
pg_upgrade ;-). The policy about post-beta1 initdb is "avoid if
practical", not "avoid at all costs".

Actually, that statement makes me realize that if we fix
PG_CONTROL_VERSION then it's a good idea to *also* do some regular catalog
changes, or at least bump catversion. Otherwise pg_upgrade won't be able to
cope with upgrading non-default tablespaces in beta1 installations.

For the moment I'll just go bump PG_CONTROL_VERSION, assuming that we have
enough other things on the table that at least one of them will result in
a catversion bump before beta2.

> Other things I'd like to change in that case:

I have no objection to these as long as we can get some consensus on the
new names (and personally I don't much care what those are, but I agree
"xmin" for a user column is a bad idea).

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2014-06-04 21:14:23 Re: Sigh, we need an initdb
Previous Message Andres Freund 2014-06-04 20:52:20 Re: Sigh, we need an initdb