From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
Cc: | Markus Wanner <markus(at)bluegap(dot)ch>, 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-06 12:26:51 |
Message-ID: | 4CAC6B0B.7000308@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 06.10.2010 15:22, Dimitri Fontaine wrote:
> What is necessary here is a clear view on the possible states that a
> standby can be in at any time, and we must stop trying to apply to
> some non-ready standby the behavior we want when it's already in-sync.
>
> From my experience operating londiste, those states would be:
>
> 1. base-backup — self explaining
> 2. catch-up — getting the WAL to catch up after base backup
> 3. wanna-sync — don't yet have all the WAL to get in sync
> 4. do-sync — all WALs are there, coming soon
> 5. ok (async | recv | fsync | reply — feedback loop engaged)
>
> So you only consider that a standby is a candidate for sync rep when
> it's reached the ok state, and that's when it's able to fill the
> feedback loop we've been talking about. Standby state != ok, no waiting
> no nothing, it's *not* a standby as far as the master is concerned.
You're not going to get zero data loss that way. Can you elaborate what
the use case for that mode is?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Selena Deckelmann | 2010-10-06 13:02:22 | Fwd: Submissions for a PostgreSQL track at MySQL Conf 2011: Due October 25 |
Previous Message | Magnus Hagander | 2010-10-06 12:25:21 | Re: querying the version of libpq |