Re: Sigh, we need an initdb

<p dir="ltr"><br /> On Jun 4, 2014 8:52 PM, "Tom Lane" <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>>
wrote:<br/> ><br /> > I just noticed that we had not one, but two commits in 9.4 that added<br /> > fields to
pg_control. And neither one changed PG_CONTROL_VERSION.<br /> > This is inexcusable sloppiness on the part of the
committersinvolved,<br /> > but the question is what do we do now?<br /> ><br /> > Quick experimentation says
thatyou don't really get to the point of<br /> > noticing this if you try to start a 9.4 postmaster against 9.3
databaseor<br /> > vice versa, because the postmaster will look at the PG_VERSION file first.<br /> > However,
pg_resetxlogand pg_controldata don't do that, so you could get<br /> > misleading results from the wrong
pg_controldataversion or potentially<br /> > screw yourself entirely with the wrong pg_resetxlog, if you failed
to<br/> > interpret their warnings about wrong CRC values correctly.<br /> ><br /> > I think we could possibly
ship9.4 without fixing this, but it would be<br /> > imprudent.  Anyone think differently?<p dir="ltr">Shipping it
withoutfixing that seems like a horrible idea. We should either force an initdb or revert those changes. <p
dir="ltr">I'dvote for forcing initdb. If we push it off we'll be paying for it for the coming 5 years. <br /><p
dir="ltr">>Of course, if we do fix this then the door opens for pushing other<br /> > initdb-forcing fixes into
9.4beta2,such as the LOBLKSIZE addition<br /> > that I was looking at when I noticed this, or the pg_lsn catalog<br
/>> additions that were being discussed a couple weeks ago.<br /><p dir="ltr">+1. We should of course evaluate those
patchesindividually  but the initdb argument against them isn't valid, so if they are otherwise good, we should accept
them.<p dir="ltr">/Magnus <br />