On Jun 4, 2014 8:52 PM, "Tom Lane" <t...@sss.pgh.pa.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
