At this point I feel that this new functionality might be a bit overkill for postgres, maybe it's better to stay lean and mean rather than add a controversial feature like this.
I also agree that a more general replication timeout variable would be more useful to a larger audience but that would in my view add more complexity to the replication code which is quite simple and understandable right now ... Anyway, my backup plan was to achieve the same thing by triggering on the logging produced on the primary server and switch to async mode when detecting that the standby replication link has failed (and then back again when it is restored). In effect I would put a replication monitor on the outside of the server instead of embedding it. /A -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
