Hannu Krosing <hannu@krosing.net> writes:
> On Wed, 2008-06-04 at 10:40 -0400, Tom Lane wrote:
>> "Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> Hmm, WAL version compatibility is an interesting question. Most minor
> releases hasn't changed the WAL format, and it would be nice to allow
> running different minor versions in the master and slave in those cases.
> But it's certainly not unheard of to change the WAL format. Perhaps we
> should introduce a WAL version number, similar to catalog version?
>>
>> Yeah, perhaps. In the past we've changed the WAL page ID field for
>> this; I'm not sure if that's enough or not. It does seem like a good
>> idea to have a way to check that the slaves aren't trying to read a
>> WAL version they don't understand. Also, it's possible that the WAL
>> format doesn't change across a major update, but you still couldn't
>> work with say an 8.4 master and an 8.3 slave, so maybe we need the
>> catalog version ID in there too.
> And something dependent on datetime being integer.
This thread is getting out of hand, actually.
Heikki's earlier comment about pg_control reminded me that we already
have a unique system identifier stored in pg_control and check that
against WAL headers. So I think we already have enough certainty that
the master and slaves have the same pg_control and hence are the same
for everything checked by pg_control.
However, since by definition pg_control doesn't change in a minor
upgrade, there isn't any easy way to enforce a rule like "slaves must be
same or newer minor version as the master". I'm not sure that we
actually *want* to enforce such a rule, though. Most of the time, the
other way around would work fine.
regards, tom lane