Re: replication commands and log_statements

On 08/28/2014 11:38 AM, Fujii Masao wrote:
> On Thu, Jun 19, 2014 at 5:29 PM, Ian Barwick <ian(at)2ndquadrant(dot)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