worker_spi: Bump up max_worker_processes in TAP tests

mamba has detected a failure in the last test that should start a
bgworker while bypassing the role login check.  The buildfarm did not
provide any information about its failure in the logs, but I suspect
that this is caused by an exhaustion of the max_worker_processes slots
set at 8 by default.

In "normal" test runs, the number of bgworkers running at this stage of
the test is already 7, so, if one of them spawns for example a parallel
worker all the slots would be taken, preventing the last worker of the
test to start.

Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/ZSyebsiub88pyJJO@paquier.xyz

1 files changed, 3 insertions, 0 deletions

diff --git a/src/test/modules/worker_spi/t/001_worker_spi.pl b/src/test/modules/worker_spi/t/001_worker_spi.pl
index 85b8934f4ea..ba1d281e81b 100644
--- a/src/test/modules/worker_spi/t/001_worker_spi.pl
+++ b/src/test/modules/worker_spi/t/001_worker_spi.pl
@@ -63,11 +63,14 @@ $node->safe_psql('postgres', q(CREATE ROLE myrole SUPERUSER LOGIN;));
 $node->safe_psql('mydb', 'CREATE EXTENSION worker_spi;');
 
 # Now load the module as a shared library.
+# Update max_worker_processes to make room for enough bgworkers, including
+# parallel workers these may spawn.
 $node->append_conf(
 	'postgresql.conf', q{
 shared_preload_libraries = 'worker_spi'
 worker_spi.database = 'mydb'
 worker_spi.total_workers = 3
+max_worker_processes = 32
 });
 $node->restart;