Thanks for reviewing the patch!

On Wed, Sep 10, 2014 at 4:57 PM, Heikki Linnakangas
<hlinnakan...@vmware.com> wrote:
> On 08/28/2014 11:38 AM, Fujii Masao wrote:
>>
>> On Thu, Jun 19, 2014 at 5:29 PM, Ian Barwick <i...@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.

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
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
***************
*** 4558,4563 **** FROM pg_stat_activity;
--- 4558,4579 ----
        </listitem>
       </varlistentry>
  
+      <varlistentry id="guc-log-replication-commands" xreflabel="log_replication_commands">
+       <term><varname>log_replication_commands</varname> (<type>boolean</type>)
+       <indexterm>
+        <primary><varname>log_replication_commands</> configuration parameter</primary>
+       </indexterm>
+       </term>
+       <listitem>
+        <para>
+         Causes each replication command to be logged in the server log.
+         See <xref linkend="protocol-replication"> for more information about
+         replication command. The default value is <literal>off</>.
+         Only superusers can change this setting.
+        </para>
+       </listitem>
+      </varlistentry>
+ 
       <varlistentry id="guc-log-temp-files" xreflabel="log_temp_files">
        <term><varname>log_temp_files</varname> (<type>integer</type>)
        <indexterm>
*** a/doc/src/sgml/protocol.sgml
--- b/doc/src/sgml/protocol.sgml
***************
*** 1306,1311 **** To initiate streaming replication, the frontend sends the
--- 1306,1313 ----
  of <literal>true</> tells the backend to go into walsender mode, wherein a
  small set of replication commands can be issued instead of SQL statements. Only
  the simple query protocol can be used in walsender mode.
+ Replication commands are logged in the server log when
+ <xref linkend="guc-log-replication-commands"> is enabled.
  Passing <literal>database</> as the value instructs walsender to connect to
  the database specified in the <literal>dbname</> parameter, which will allow
  the connection to be used for logical replication from that database.
*** a/src/backend/replication/walsender.c
--- b/src/backend/replication/walsender.c
***************
*** 108,113 **** bool		am_db_walsender = false;	/* Connected to a database? */
--- 108,114 ----
  int			max_wal_senders = 0;	/* the maximum number of concurrent walsenders */
  int			wal_sender_timeout = 60 * 1000;		/* maximum time to send one
  												 * WAL data message */
+ bool		log_replication_commands = false;
  
  /*
   * State for WalSndWakeupRequest
***************
*** 1268,1280 **** exec_replication_command(const char *cmd_string)
  	MemoryContext old_context;
  
  	/*
  	 * CREATE_REPLICATION_SLOT ... LOGICAL exports a snapshot until the next
  	 * command arrives. Clean up the old stuff if there's anything.
  	 */
  	SnapBuildClearExportedSnapshot();
  
- 	elog(DEBUG1, "received replication command: %s", cmd_string);
- 
  	CHECK_FOR_INTERRUPTS();
  
  	cmd_context = AllocSetContextCreate(CurrentMemoryContext,
--- 1269,1287 ----
  	MemoryContext old_context;
  
  	/*
+ 	 * Log replication command if log_replication_commands is enabled.
+ 	 * Even when it's disabled, log the command with DEBUG1 level for
+ 	 * backward compatibility.
+ 	 */
+ 	ereport(log_replication_commands ? LOG : DEBUG1,
+ 			(errmsg("received replication command: %s", cmd_string)));
+ 
+ 	/*
  	 * CREATE_REPLICATION_SLOT ... LOGICAL exports a snapshot until the next
  	 * command arrives. Clean up the old stuff if there's anything.
  	 */
  	SnapBuildClearExportedSnapshot();
  
  	CHECK_FOR_INTERRUPTS();
  
  	cmd_context = AllocSetContextCreate(CurrentMemoryContext,
*** a/src/backend/utils/misc/guc.c
--- b/src/backend/utils/misc/guc.c
***************
*** 925,930 **** static struct config_bool ConfigureNamesBool[] =
--- 925,939 ----
  		NULL, NULL, NULL
  	},
  	{
+ 		{"log_replication_commands", PGC_SUSET, LOGGING_WHAT,
+ 			gettext_noop("Logs each replication command."),
+ 			NULL
+ 		},
+ 		&log_replication_commands,
+ 		false,
+ 		NULL, NULL, NULL
+ 	},
+ 	{
  		{"debug_assertions", PGC_INTERNAL, PRESET_OPTIONS,
  			gettext_noop("Shows whether the running server has assertion checks enabled."),
  			NULL,
*** a/src/backend/utils/misc/postgresql.conf.sample
--- b/src/backend/utils/misc/postgresql.conf.sample
***************
*** 431,436 ****
--- 431,437 ----
  					# e.g. '<%u%%%d> '
  #log_lock_waits = off			# log lock waits >= deadlock_timeout
  #log_statement = 'none'			# none, ddl, mod, all
+ #log_replication_commands = off
  #log_temp_files = -1			# log temporary files equal or larger
  					# than the specified size in kilobytes;
  					# -1 disables, 0 logs all temp files
*** a/src/include/replication/walsender.h
--- b/src/include/replication/walsender.h
***************
*** 25,30 **** extern bool wake_wal_senders;
--- 25,31 ----
  /* user-settable parameters */
  extern int	max_wal_senders;
  extern int	wal_sender_timeout;
+ extern bool	log_replication_commands;
  
  extern void InitWalSender(void);
  extern void exec_replication_command(const char *query_string);
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to