Re: Replication logging - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Replication logging
Date
Msg-id 4D353E28.8050400@enterprisedb.com
Whole thread Raw
In response to Re: Replication logging  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Replication logging
Re: Replication logging
List pgsql-hackers
On 17.01.2011 21:04, Robert Haas wrote:
> On Mon, Jan 17, 2011 at 1:57 PM, Tom Lane<tgl@sss.pgh.pa.us>  wrote:
>> I'm of the opinion that the correct way of "lowering in later releases"
>> is to make the messages obey Log_connections.  The "needed for debug"
>> argument seems mighty weak to me even for the time, and surely falls
>> down now.
>
> On a busy system, you could have a pretty high rate of messages
> spewing forth for regular connections - that's a lot to wade through
> if all you really want to see are the replication connections, which
> should be much lower volume.  But I guess now that we have
> pg_stat_replication it's a little easier to see the status of
> replication anyway.  On the whole I've found the default setting here
> very pleasant, so I'm reluctant to change it, but it sounds like I
> might be out-voted.

I also find it weird that incoming replication connections are logged by 
default. In the standby, we also log "streaming replication successfully 
connected to primary", which serves much of the same debugging purpose. 
That standby-side message is ok, we have a tradition of being more 
verbose during recovery, we also emit the "restored log file \"%s\" from 
archive" message for every WAL segment restored from archive for example.

We could turn log_connections into an enum, like log_statement:

log_connections = 'none'    # none, replication, regular, all

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: We need to log aborted autovacuums
Next
From: Simone Aiken
Date:
Subject: Re: ToDo List Item - System Table Index Clustering