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