From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Cc: | "Stephen Denne" <Stephen(dot)Denne(at)datamail(dot)co(dot)nz>, "Hannu Krosing" <hannu(at)krosing(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Core team statement on replication in PostgreSQL |
Date: | 2008-06-04 14:40:58 |
Message-ID: | 24477.1212590458@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy pgsql-hackers |
"Heikki Linnakangas" <heikki(at)enterprisedb(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2008-06-04 15:27:04 | Re: Core team statement on replication in PostgreSQL |
Previous Message | Andrew Sullivan | 2008-06-04 14:36:23 | Re: Core team statement on replication in PostgreSQL |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-06-04 14:56:44 | Re: Proposal: new function array_init |
Previous Message | Andrew Sullivan | 2008-06-04 14:36:23 | Re: Core team statement on replication in PostgreSQL |