| From: | Markus Wanner <markus(at)bluegap(dot)ch> |
|---|---|
| To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
| Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, 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 09:57:27 |
| Message-ID: | 4CAEEB07.2050404@bluegap.ch |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 10/08/2010 11:41 AM, Dimitri Fontaine wrote:
> Same old story. Either you're able to try and fix the master so that you
> don't lose any data and don't even have to check for that, or you take a
> risk and start from a non synced standby. It's all availability against
> durability again.
..and a whole lot of manual work, that's prone to error for something
that could easily be automated, at certainly less than 2000 EUR initial,
additional cost (if any at all, in case you already have three servers).
Sorry, I still fail to understand that use case.
It reminds me of the customer that wanted to save the cost of the BBU
and ran with fsync=off. Until his server got down due to a power outage.
But yeah, we provide that option as well, yes. Point taken.
Regards
Markus Wanner
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dimitri Fontaine | 2010-10-08 10:05:26 | Re: Issues with Quorum Commit |
| Previous Message | Dimitri Fontaine | 2010-10-08 09:41:00 | Re: Issues with Quorum Commit |