Re: Core team statement on replication in PostgreSQL

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