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

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-10-01 03:17:54 Re: [Patch] Optimize dropping of relation buffers using dlist
Previous Message osumi.takamichi@fujitsu.com 2020-10-01 03:04:38 RE: Disable WAL logging to speed up data loading