worker_spi: Bump up max_worker_processes in TAP tests
authorMichael Paquier <michael@paquier.xyz>
Mon, 16 Oct 2023 04:07:36 +0000 (13:07 +0900)
committerMichael Paquier <michael@paquier.xyz>
Mon, 16 Oct 2023 04:07:36 +0000 (13:07 +0900)
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

src/test/modules/worker_spi/t/001_worker_spi.pl

index 85b8934f4eab4c4ecb58aaa9eb01aa89591d9ed6..ba1d281e81b521473f594007509851d36f30ec3f 100644 (file)
@@ -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;