Re: replication commands and log_statements

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Ian Barwick <ian(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: replication commands and log_statements
Date: 2014-09-10 10:39:23
Message-ID: CAHGQGwEZB4ERpB3mgP+P494HQq=FsYpZXHqEuPWMS4Y7g_5FGw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Regards,

--
Fujii Masao

Attachment Content-Type Size
log_replication_command_v4.patch text/x-patch 4.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2014-09-10 11:13:50 Re: Add shutdown_at_recovery_target option to recovery.conf
Previous Message Marko Tiikkaja 2014-09-10 10:18:41 Re: LIMIT for UPDATE and DELETE