Horton

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

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, pgsql-hackers@lists.postgresql.org, Noah Misch <noah@leadboat.com>
Date: 2020-10-01T03:15:38Z
Lists: pgsql-hackers 
On Tue, Sep 29, 2020 at 07:04:22PM -0400, Tom Lane wrote:
> Hm.  We could do so back to v10 where that came in, and there are no
> src/test/subscription tests before v10, so that should be sufficient.
> Sold.

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, and PGHOST gets set to the domain path when initializing
PostgresNode.pm for all the nodes involved in a test, so pg_receivewal
should connect to the correct node.  The only think I can think of is
that the environment enforces max_wal_senders to 0 in this build.
Noah, is this machine doing anything specific?
--
Michael

Commits

  1. Put back explicit setting of replication values within TAP tests.

  2. Remove obsolete replication settings within TAP tests.

  3. Honor TEMP_CONFIG in TAP suites.

  4. Move some code from RewindTest into PostgresNode