Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> 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?
You can't pretend to sync with zero data loss until the standby is ready
for it, or you need to take the site down while you add your standby.
I can see some user willing to take the site down while doing the base
backup dance then waiting for initial sync, then only accepting traffic
and being secure against data loss, but I'd much rather that be an
option and you could watch for your standby's state in a system view.
Meanwhile, I can't understand any reason for the master to pretend it
can safely manage any sync-rep transaction while there's no standby
around. Either you wait for the quorum and don't have it, or you have to
track standby states with precision and maybe actively reject writes.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support