Re: Why does PostgresNode.pm set such a low value of max_wal_senders?

From: Noah Misch <noah(at)leadboat(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Why does PostgresNode.pm set such a low value of max_wal_senders?
Date: 2020-10-01 05:38:59
Message-ID: 20201001053859.GA1191753@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 29, 2020 at 06:13:46PM -0400, Tom Lane wrote:
> So I wonder why PostgresNode.pm is doing
>
> print $conf "max_wal_senders = 5\n";
>
> Considering that our default these days is 10 senders, and that a
> walsender slot doesn't really cost much, this seems unduly cheapskate.
> I propose raising this to 10.

In favor of minimal values, we've had semaphore-starved buildfarm members in
the past. Perhaps those days are over, seeing that this commit has not yet
broken a buildfarm member in that particular way. Keeping max_wal_senders=10
seems fine.

On Thu, Oct 01, 2020 at 12:15:38PM +0900, Michael Paquier wrote:
> Since this stuff has been committed, thorntail has showed a very
> interesting failure with only the TAP tests of pg_receivewal:
> # Running: pg_receivewal --slot test --create-slot
> pg_receivewal: error: could not connect to server: FATAL: number of
> requested standby connections exceeds max_wal_senders (currently 0)
> not ok 13 - creating a replication slot
>
> This animal uses the following, however this should have zero impact
> on the way the configuration is done for nodes of the TAP tests as
> that's independent:
> UBSan; force_parallel_mode; wal_level=minimal
>
> extra_config in the buildfarm conf file does not impact the nodes of
> TAP tests

No, PostgreSQL commit 54c2ecb changed that. I recommend an explicit
max_wal_senders=10 in PostgresNode, which makes it easy to test
wal_level=minimal:

printf '%s\n%s\n%s\n' 'log_statement = all' 'wal_level = minimal' 'max_wal_senders = 0' >/tmp/minimal.conf
make check-world TEMP_CONFIG=/tmp/minimal.conf

thorntail is doing the equivalent, hence the failures.

Perhaps wal_level=minimal should stop its pedantic call for max_wal_senders=0.
As long as the relevant error messages are clear, it would be fine for
wal_level=minimal to ignore max_wal_senders and size resources as though
max_wal_senders=0. That could be one less snag for end users. (It's not
worth changing solely to save a line in PostgresNode, though.)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message k.jamison@fujitsu.com 2020-10-01 05:43:34 RE: [Patch] Optimize dropping of relation buffers using dlist
Previous Message Kyotaro Horiguchi 2020-10-01 05:09:09 Re: [Patch] Optimize dropping of relation buffers using dlist