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

From Tom Lane
Subject Sigh, we need an initdb
Date
Msg-id 1159.1401907955@sss.pgh.pa.us
Whole thread Raw
Responses Re: Sigh, we need an initdb  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: Sigh, we need an initdb  (Magnus Hagander <magnus@hagander.net>)
Re: Sigh, we need an initdb  (Robert Haas <robertmhaas@gmail.com>)
Re: Sigh, we need an initdb  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
I just noticed that we had not one, but two commits in 9.4 that added
fields to pg_control.  And neither one changed PG_CONTROL_VERSION.
This is inexcusable sloppiness on the part of the committers involved,
but the question is what do we do now?

Quick experimentation says that you don't really get to the point of
noticing this if you try to start a 9.4 postmaster against 9.3 database or
vice versa, because the postmaster will look at the PG_VERSION file first.
However, pg_resetxlog and pg_controldata don't do that, so you could get
misleading results from the wrong pg_controldata version or potentially
screw yourself entirely with the wrong pg_resetxlog, if you failed to
interpret their warnings about wrong CRC values correctly.

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Proposing pg_hibernate
Next
From: Andres Freund
Date:
Subject: Re: Proposing pg_hibernate