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 <simon@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
