Re: Sigh, we need an initdb

On Jun 4, 2014 8:52 PM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> 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?

Shipping it without fixing that seems like a horrible idea. We should
either force an initdb or revert those changes.

I'd vote for forcing initdb. If we push it off we'll be paying for it for
the coming 5 years.

> 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.

+1. We should of course evaluate those patches individually but the initdb
argument against them isn't valid, so if they are otherwise good, we should
accept them.

/Magnus