From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Thomas Munro <thomas.munro@gmail.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: pgsql-docs@lists.postgresql.org
Subject: Re: wal_init_zero and wal_recycle
Date: Fri, 29 May 2020 13:13:34 +0900
Message-ID: <ee25c1cc-624b-1043-bd77-f6a9262a1b97@oss.nttdata.com> (raw)
In-Reply-To: <CA+hUKGLZ0WPUZiD+2Yehxx_ToBqur2A4-md6GDZ80HJr9moWdw@mail.gmail.com>
References: <b5190ab4-a169-6a42-0e49-aed0807c8976@oss.nttdata.com>
<CANP8+jJ0NnEnXbe+Rp-T1u-irLX61wtKJ5ORSx8WZW2HtjtOXw@mail.gmail.com>
<CA+hUKGLZ0WPUZiD+2Yehxx_ToBqur2A4-md6GDZ80HJr9moWdw@mail.gmail.com>
On 2020/05/28 8:43, Thomas Munro wrote:
> On Wed, May 27, 2020 at 7:09 PM Simon Riggs <simon@2ndquadrant.com> wrote:
>> On Wed, 27 May 2020 at 04:27, Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>>>
>>> Hi,
>>>
>>> The group of wal_init_zero and wal_recycle is WAL_SETTINGS in guc.c,
>>> but their descriptions are located in "19.6. Replication"/"19.6.1. Sending
>>> Servers" section. This seems a documentation bug. They should be located
>>> in "19.5. Write Ahead Log"/"19.5.1. Settings". Thought?
>>
>>
>> +1
Thanks! Patch attached.
Since they are located just before wal_buffers in postgresql.conf.sample,
I moved the descriptions of them also just before that of wal_buffers
in "Write Ahead Log"/"Settings" section.
BTW, while reading guc.c, I found the GUC context of wal_recycle is
PGC_SUSET. But isn't it better to set it to PGC_SIGHUP because wal_recycle
doesn't affect any backends? Basically checkpointer and startup process
use wal_recycle.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Attachments:wal_guc_docs.patch (text/plain, 3.8K) downloaddiff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgmlindex a2694e548a..862baae0c8 100644--- a/doc/src/sgml/config.sgml+++ b/doc/src/sgml/config.sgml@@ -2820,6 +2820,41 @@ include_dir 'conf.d'
</listitem>
</varlistentry>
+ <varlistentry id="guc-wal-init-zero" xreflabel="wal_init_zero">+ <term><varname>wal_init_zero</varname> (<type>boolean</type>)+ <indexterm>+ <primary><varname>wal_init_zero</varname> configuration parameter</primary>+ </indexterm>+ </term>+ <listitem>+ <para>+ If set to <literal>on</literal> (the default), this option causes new+ WAL files to be filled with zeroes. On some file systems, this ensures+ that space is allocated before we need to write WAL records. However,+ <firstterm>Copy-On-Write</firstterm> (COW) file systems may not benefit+ from this technique, so the option is given to skip the unnecessary+ work. If set to <literal>off</literal>, only the final byte is written+ when the file is created so that it has the expected size.+ </para>+ </listitem>+ </varlistentry>++ <varlistentry id="guc-wal-recycle" xreflabel="wal_recycle">+ <term><varname>wal_recycle</varname> (<type>boolean</type>)+ <indexterm>+ <primary><varname>wal_recycle</varname> configuration parameter</primary>+ </indexterm>+ </term>+ <listitem>+ <para>+ If set to <literal>on</literal> (the default), this option causes WAL+ files to be recycled by renaming them, avoiding the need to create new+ ones. On COW file systems, it may be faster to create new ones, so the+ option is given to disable this behavior.+ </para>+ </listitem>+ </varlistentry>+
<varlistentry id="guc-wal-buffers" xreflabel="wal_buffers">
<term><varname>wal_buffers</varname> (<type>integer</type>)
<indexterm>
@@ -3752,41 +3787,6 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
</listitem>
</varlistentry>
- <varlistentry id="guc-wal-init-zero" xreflabel="wal_init_zero">- <term><varname>wal_init_zero</varname> (<type>boolean</type>)- <indexterm>- <primary><varname>wal_init_zero</varname> configuration parameter</primary>- </indexterm>- </term>- <listitem>- <para>- If set to <literal>on</literal> (the default), this option causes new- WAL files to be filled with zeroes. On some file systems, this ensures- that space is allocated before we need to write WAL records. However,- <firstterm>Copy-On-Write</firstterm> (COW) file systems may not benefit- from this technique, so the option is given to skip the unnecessary- work. If set to <literal>off</literal>, only the final byte is written- when the file is created so that it has the expected size.- </para>- </listitem>- </varlistentry>-- <varlistentry id="guc-wal-recycle" xreflabel="wal_recycle">- <term><varname>wal_recycle</varname> (<type>boolean</type>)- <indexterm>- <primary><varname>wal_recycle</varname> configuration parameter</primary>- </indexterm>- </term>- <listitem>- <para>- If set to <literal>on</literal> (the default), this option causes WAL- files to be recycled by renaming them, avoiding the need to create new- ones. On COW file systems, it may be faster to create new ones, so the- option is given to disable this behavior.- </para>- </listitem>- </varlistentry>-
<varlistentry id="guc-max-slot-wal-keep-size" xreflabel="max_slot_wal_keep_size">
<term><varname>max_slot_wal_keep_size</varname> (<type>integer</type>)
<indexterm>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-docs@postgresql.org
Cc: masao.fujii@oss.nttdata.com, thomas.munro@gmail.com, simon@2ndquadrant.com, pgsql-docs@lists.postgresql.org
Subject: Re: wal_init_zero and wal_recycle
In-Reply-To: <ee25c1cc-624b-1043-bd77-f6a9262a1b97@oss.nttdata.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox