Re: Version number for pg_control
От | Tom Lane |
---|---|
Тема | Re: Version number for pg_control |
Дата | |
Msg-id | 17827.1468623076@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Version number for pg_control (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: