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