On Wed, Sep 2, 2015 at 12:03:36PM -0700, Josh Berkus wrote: > Well, there is a WIP patch for that, which IMHO would be much improved > by having a concrete use-case like this one. What nobody is working on > -- and we've vetoed in the past -- is a way of automatically failing and > removing from replication any node which repeatedly fails to sync, which > would be a requirement for this model. > > You'd also need a way to let the connection nodes know when a replica > has fallen behind so that they can be taken out of > load-balancing/sharding for read queries. For the synchronous model, > that would be "fallen behind at all"; for asynchronous it would be > "fallen more than ### behind".
I think this gets back to the idea of running an administrative alert command when we switch to using a different server for synchronous_standby_names. We can't just keep requiring external tooling to identify things that the database knows easily and can send an alert. Removing failed nodes is also something we should do and notify users about. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
