| From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(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 10:00:42 |
| Message-ID: | m2iq24665x.fsf@hi-media.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> If the synchronicity is configured in the standby, how does the master know
> that there's a synchronous slave out there that it should wait for, if that
> slave isn't connected at the moment?
That's what quorum is trying to solve. The master knows how many votes
per sync level the transaction needs. If no slave is acknowledging any
vote, that's all you need to know to ROLLBACK (after the timeout),
right? — if setup says so, on the master.
> Yeah, the quorum stuff. That's all good, but doesn't change the way you
> would do per-transaction control.
That's when I bought in on the feature. It's all dynamic and
distributed, and it offers per-transaction control.
Regards,
--
Dimitri Fontaine
PostgreSQL DBA, Architecte
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2010-09-17 10:02:57 | Re: Configuring synchronous replication |
| Previous Message | Simon Riggs | 2010-09-17 09:49:29 | Re: Configuring synchronous replication |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2010-09-17 10:02:57 | Re: Configuring synchronous replication |
| Previous Message | Fujii Masao | 2010-09-17 09:52:24 | trigger failover with signal |