Re: [HACKERS] Version number for pg_control

2016-07-17 Thread Craig Ringer
On 15 July 2016 at 23:54, 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.
>
> 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.

-- 
 Craig Ringer   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


Re: [HACKERS] Version number for pg_control

2016-07-15 Thread Tom Lane
I wrote:
> David Steele  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-04e3f87fc...@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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Version number for pg_control

2016-07-15 Thread David Steele
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
da...@pgmasters.net


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Version number for pg_control

2016-07-15 Thread Tom Lane
David Steele  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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Version number for pg_control

2016-07-15 Thread David Steele
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
da...@pgmasters.net


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Version number for pg_control

2016-07-15 Thread Alvaro Herrera
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 Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Version number for pg_control

2016-07-15 Thread Alvaro Herrera
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 Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers