From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | fazool mein <fazoolmein(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Timeline in the light of Synchronous replication |
Date: | 2010-10-19 17:32:25 |
Message-ID: | AANLkTinpGDqR7Rmdb=y51Hhg-RUFScRBD3_xEknrK+zJ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 18, 2010 at 4:31 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> But, even though we will have done that, it should be noted that WAL in
> A might be ahead of that in B. For example, A might crash right after
> writing WAL to the disk and before sending it to B. So when we restart
> the old master A as the standby after failover, we should need to delete
> some WAL files (in A) which are inconsistent with the WAL sequence in B.
Right. There's no way to make it categorically safe to turn A into a
standby, because there's no way to guarantee that the fsyncs of the
WAL happen at the same femtosecond on both machines. What we should
be looking for is a reliable way to determine whether or not it is in
fact safe. Timelines are intended to provide that, but there are
holes, so they don't.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Marios Vodas | 2010-10-19 17:46:18 | gist DatumGetPointer returns pointer to corrupted data |
Previous Message | Marios Vodas | 2010-10-19 17:12:35 | Re: knngist plans |