| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Heikki Linnakangas <heikki(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Configuring synchronous replication |
| Date: | 2010-09-17 12:43:59 |
| Message-ID: | AANLkTimbd6ExgLX5k1MZrMFKoVUep1ccBUUxQPB4h=ch@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
On Fri, Sep 17, 2010 at 5:09 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> * Quorum commit. Wait until n standbys acknowledge. n=1 and n=all servers
> can be seen as important special cases of this.
I think that we should skip quorum commit at the first phase
because the design seems to be still poorly-thought-out.
I'm concerned about the case where the faster synchronous standby
goes down and the lagged synchronous one remains when n=1. In this
case, some transactions marked as committed in a client might not
be replicated to the remaining synchronous standby yet. What if
the master goes down at this point? How can we determine whether
promoting the remaining standby to the master causes data loss?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-09-17 12:49:30 | Re: Configuring synchronous replication |
| Previous Message | Simon Riggs | 2010-09-17 12:40:42 | Re: Configuring synchronous replication |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-09-17 12:49:30 | Re: Configuring synchronous replication |
| Previous Message | Simon Riggs | 2010-09-17 12:40:42 | Re: Configuring synchronous replication |