Re: replication commands and log_statements - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: replication commands and log_statements
Date
Msg-id 5410047A.4070500@vmware.com
Whole thread Raw
In response to Re: replication commands and log_statements  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: replication commands and log_statements  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
On 08/28/2014 11:38 AM, Fujii Masao wrote:
> On Thu, Jun 19, 2014 at 5:29 PM, Ian Barwick <ian@2ndquadrant.com> wrote:
>> - minor rewording for the description, mentioning that statements will
>>    still be logged as DEBUG1 even if parameter set to 'off' (might
>>    prevent reports of the kind "I set it to 'off', why am I still seeing
>>    log entries?").
>>
>>         <para>
>>          Causes each replication command to be logged in the server log.
>>          See <xref linkend="protocol-replication"> for more information about
>>          replication commands. The default value is <literal>off</>. When set
>> to
>>          <literal>off</>, commands will be logged at log level
>> <literal>DEBUG1</literal>.
>>          Only superusers can change this setting.
>>         </para>
>
> Yep, fixed. Attached is the updated version of the patch.

I don't think it's necessary to mention that the commands will still be 
logged at DEBUG1 level. We log all kinds of crap at the various DEBUG 
levels, and they're not supposed to be used in normal operation.

>> - I feel it would be more consistent to use the plural form
>>    for this parameter, i.e. "log_replication_commands", in line with
>>    "log_lock_waits", "log_temp_files", "log_disconnections" etc.
>
> But log_statement is in the singular form. So I just used
> log_replication_command. For the consistency, maybe we need to
> change both parameters in the plural form? I don't have strong
> opinion about this.

Yeah, we seem to be inconsistent. log_replication_commands would sound 
better to me in isolation, but then there is log_statement..

I'll mark this as Ready for Committer in the commitfest app (I assume 
you'll take care of committing this yourself when ready).

- Heikki




pgsql-hackers by date:

Previous
From: Marko Tiikkaja
Date:
Subject: Re: LIMIT for UPDATE and DELETE
Next
From: Mark Kirkwood
Date:
Subject: Re: Scaling shared buffer eviction