Thread: Version number for pg_control
While researching a pgsql-general question, I noticed that commit
73c986adde5d73a5e2555da9b5c8facedb146dcd added several new fields
to pg_control without bothering to touch PG_CONTROL_VERSION. Thus,
PG_CONTROL_VERSION is still "942" even though the file contents
are not at all compatible with 9.4.
It's way too late to do anything about this in 9.5. I wonder though
if we should advance PG_CONTROL_VERSION now, presumably to "960",
so that at least as of 9.6 the format is correctly distinguished
from the 9.4-era format. Or will that just make things even more
confusing, given that 9.5 is what it is?
regards, tom lane
Tom Lane wrote: > While researching a pgsql-general question, I noticed that commit > 73c986adde5d73a5e2555da9b5c8facedb146dcd added several new fields > to pg_control without bothering to touch PG_CONTROL_VERSION. Thus, > PG_CONTROL_VERSION is still "942" even though the file contents > are not at all compatible with 9.4. Oh crap :-( > It's way too late to do anything about this in 9.5. I wonder though > if we should advance PG_CONTROL_VERSION now, presumably to "960", > so that at least as of 9.6 the format is correctly distinguished > from the 9.4-era format. Or will that just make things even more > confusing, given that 9.5 is what it is? I can't quite make up my mind about it. It seems pointless to change it now, but at the same time it seems wrong to let it continue to be unchanged from 9.4. I slightly lean towards changing it in 9.6. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
David Steele wrote: > On 7/15/16 5:47 PM, Alvaro Herrera wrote: > > I can't quite make up my mind about it. It seems pointless to change > > it now, but at the same time it seems wrong to let it continue to be > > unchanged from 9.4. > > > > I slightly lean towards changing it in 9.6. > > +1 for changing it. However, I don't think it's such a big deal since > each version since 8.3 (at least) has had a unique catalog version. > > Maybe this would affect pg_controldata or other supporting utilities but > the server itself should not be affected since it also checks the > catalog version. I didn't verify pg_resetxlog behavior, but hypothetically running 9.4's on a 9.5 installation would result in a broken pg_control file. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 7/15/16 5:47 PM, Alvaro Herrera wrote: > Tom Lane wrote: >> While researching a pgsql-general question, I noticed that commit >> 73c986adde5d73a5e2555da9b5c8facedb146dcd added several new fields >> to pg_control without bothering to touch PG_CONTROL_VERSION. Thus, >> PG_CONTROL_VERSION is still "942" even though the file contents >> are not at all compatible with 9.4. > > Oh crap :-( > >> It's way too late to do anything about this in 9.5. I wonder though >> if we should advance PG_CONTROL_VERSION now, presumably to "960", >> so that at least as of 9.6 the format is correctly distinguished >> from the 9.4-era format. Or will that just make things even more >> confusing, given that 9.5 is what it is? > > I can't quite make up my mind about it. It seems pointless to change > it now, but at the same time it seems wrong to let it continue to be > unchanged from 9.4. > > I slightly lean towards changing it in 9.6. +1 for changing it. However, I don't think it's such a big deal since each version since 8.3 (at least) has had a unique catalog version. Maybe this would affect pg_controldata or other supporting utilities but the server itself should not be affected since it also checks the catalog version. -- -David david@pgmasters.net
David Steele <david@pgmasters.net> writes:
> +1 for changing it. However, I don't think it's such a big deal since
> each version since 8.3 (at least) has had a unique catalog version.
> Maybe this would affect pg_controldata or other supporting utilities but
> the server itself should not be affected since it also checks the
> catalog version.
Right, that version number exists mostly for the benefit of pg_controldata
and allied utilities. You would get a CRC failure in any case when trying
to go between inconsistent notions of what pg_control contains, but the
version number is supposed to help you figure out why that happened.
As things stand, though, it'd only mislead you.
regards, tom lane
On 7/15/16 6:13 PM, Alvaro Herrera wrote: > David Steele wrote: >> On 7/15/16 5:47 PM, Alvaro Herrera wrote: > >>> I can't quite make up my mind about it. It seems pointless to change >>> it now, but at the same time it seems wrong to let it continue to be >>> unchanged from 9.4. >>> >>> I slightly lean towards changing it in 9.6. >> >> +1 for changing it. However, I don't think it's such a big deal since >> each version since 8.3 (at least) has had a unique catalog version. >> >> Maybe this would affect pg_controldata or other supporting utilities but >> the server itself should not be affected since it also checks the >> catalog version. > > I didn't verify pg_resetxlog behavior, but hypothetically running 9.4's > on a 9.5 installation would result in a broken pg_control file. Yuck. I think of the utilities as read-only but there are obviously some notable exceptions. So +2 for this change. Why propagate that mess into the future? -- -David david@pgmasters.net
I wrote: > David Steele <david@pgmasters.net> writes: >> Maybe this would affect pg_controldata or other supporting utilities but >> the server itself should not be affected since it also checks the >> catalog version. > Right, that version number exists mostly for the benefit of pg_controldata > and allied utilities. You would get a CRC failure in any case when trying > to go between inconsistent notions of what pg_control contains, but the > version number is supposed to help you figure out why that happened. > As things stand, though, it'd only mislead you. Also notice that the server itself uses that heuristic to try to be helpful about the reason for a pg_control read failure: it detects PG_CONTROL_VERSION mismatch first, then checks CRC, then checks catversion (see ReadControlFile(), which even goes to the trouble of trying to diagnose endian issues this way). So the users-eye view of the problem here is that starting a 9.5 or 9.6 server against a 9.4 pg_control file will tell you that there's a checksum problem, not that the file is the wrong version. The value of getting this right was shown only today: https://www.postgresql.org/message-id/6f746a21-ccfe-d736-57cf-04e3f87fcfa5@wintek.com where we'd have had a heckuva harder time diagnosing what was up with a less on-point error message. Like Alvaro, I was on the fence about whether it is worth changing now; but this consideration makes me think that it is. regards, tom lane
On 15 July 2016 at 23:54, Tom Lane <tgl@sss.pgh.pa.us> wrote:
While researching a pgsql-general question, I noticed that commit
73c986adde5d73a5e2555da9b5c8facedb146dcd added several new fields
to pg_control without bothering to touch PG_CONTROL_VERSION. Thus,
PG_CONTROL_VERSION is still "942" even though the file contents
are not at all compatible with 9.4.
It's way too late to do anything about this in 9.5.
Is it?
If PG_VERSION and the catalog version are correct for 9.5, the next point release could update pg_control's version, accepting the old one during recovery but only writing the new one.
Whether we should is another matter, since that means people can't downgrade to old point releases, replicas will break if they upgrade the master before the replicas, etc. It doesn't seem worth the cost/benefit.