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.)
