| From: | Markus Wanner <markus(at)bluegap(dot)ch> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Issues with Quorum Commit |
| Date: | 2010-10-08 14:26:47 |
| Message-ID: | 4CAF2A27.6070904@bluegap.ch |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 10/08/2010 04:11 PM, Tom Lane wrote:
> Actually, #2 seems rather difficult even if you want it. Presumably
> you'd like to keep that state in reliable storage, so it survives master
> crashes. But how you gonna commit a change to that state, if you just
> lost every standby (suppose master's ethernet cable got unplugged)?
IIUC you seem to assume that the master node keeps its master role. But
users who value availability a lot certainly want automatic fail-over,
so any node can potentially be the new master.
After recovery from a full-cluster outage, the first question is which
node was the most recent master (or which former standby is up to date
and could take over).
Regards
Markus Wanner
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dimitri Fontaine | 2010-10-08 14:35:17 | Re: Issues with Quorum Commit |
| Previous Message | Fujii Masao | 2010-10-08 14:26:03 | Re: Issues with Quorum Commit |