On Wed, Oct 6, 2010 at 9:22 PM, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: > 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)
I agree to mange these standby states in a different standpoint. To avoid data loss, we must not promote the standby which is catching up with the master in half way to the new master at the failover. If clusterware can get the current standby state via SQL, it can check whether the failover causes data loss or not and give up failover before creating the trigger file. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
