Re: Doc about how to set max_wal_senders when setting minimal wal_level - Mailing list pgsql-hackers

From Japin Li
Subject Re: Doc about how to set max_wal_senders when setting minimal wal_level
Date
Msg-id MEYP282MB1669D35AEAB838638C97BFF6B68B9@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
Whole thread Raw
In response to Re: Doc about how to set max_wal_senders when setting minimal wal_level  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Doc about how to set max_wal_senders when setting minimal wal_level
List pgsql-hackers
Sorry for the late reply.

On Wed, 06 Jul 2022 at 08:02, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Japin Li <japinli@hotmail.com> writes:
>> [ v4-wal-level-documentation.patch ]
>
> Hm, I don't care for the wording here:
>
> +        A precondition for using minimal WAL is to disable WAL archiving and
> +        streaming replication by setting <varname>archive_mode</varname> to
> +        <literal>off</literal>, and <xref linkend="guc-max-wal-senders"/> to
> +        <literal>0</literal>.
>
> "Precondition" is an overly fancy word that makes things less clear
> not more so.  Does it mean that setting wal_level = minimal will fail
> if you don't do these other things, or does it just mean that you
> won't be getting the absolute minimum WAL volume?  If the former,
> I think it'd be better to say something like "To set wal_level to minimal,
> you must also set [these variables], which has the effect of disabling
> both WAL archiving and streaming replication."

Yeah, it's the former case.

>
> +        servers.  If setting <varname>max_wal_senders</varname> to
> +        <literal>0</literal> consider also reducing the amount of WAL produced
> +        by changing <varname>wal_level</varname> to <literal>minimal</literal>.
>
> I don't think this is great advice.  It will encourage people to use
> wal_level = minimal even if they have other requirements that weigh
> against it.  If they feel that their system is producing too much
> WAL, I doubt they'll have a hard time finding the wal_level knob.
>

Agreed. It isn't good advice.  We can remove the suggestion.


--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Allowing REINDEX to have an optional name
Next
From: Tom Lane
Date:
Subject: Re: EINTR in ftruncate()