Re: replication commands and log_statements

On Wed, Sep 10, 2014 at 7:39 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> Thanks for reviewing the patch!
>
> On Wed, Sep 10, 2014 at 4:57 PM, Heikki Linnakangas
> <hlinnakangas(at)vmware(dot)com> wrote:
>> 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.
>
> Agreed. I removed that mention from the document.
>
>>
>>>> - 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..
>
> Agreed. I changed the GUC name to log_replication_commands.
>
>>
>> I'll mark this as Ready for Committer in the commitfest app (I assume you'll
>> take care of committing this yourself when ready).
>
> Attached is the updated version of the patch. After at least one day
> I will commit the patch.

Applied. Thanks all!

Regards,

--
Fujii Masao