On Jan19, 2011, at 16:16 , Simon Riggs wrote: > On Wed, 2011-01-19 at 09:08 -0500, Robert Haas wrote: >> On Wed, Jan 19, 2011 at 7:55 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >>> How will we diagnose erratic connection problems now? >> >> As Heikki pointed out, the slave still logs this information, so we >> can look there. If that's enough, yeah, you'll have to turn >> log_connections on on the master, but I don't think that will be very >> frequent, and it's not an unmanageable burden anyway. > > So now we have to check *all* of the standby logs in order to check that > replication on the master is working without problems. There will be no > default capability to tie up events on the master with failures of > replication. Events occurring on multiple standbys will not be picked up > as a correlated set of events.
I don't see for what kind of problems logging replication connections is the right way to monitor replication. To check that all slaves are connected and are streaming WAL, one ought to monitor pg_stat_replication, no? Once a slave vanishes from there (or falls back too far) you'd inspect the *slave's* log to find the reason. Inspecting the master's log instead will always be a poor replacement, since some failure conditions won't leave a trace there (Connectivity problems, for example). Could you explain the failure condition you do have in mind where logging replication connections unconditionally is beneficial? best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
