[Patch] Improve the test src/test/postmaster/t/003_start_stop.pl
Hello,
This is about the TAP test src/test/postmaster/t/003_start_stop.pl. The test contains a loop that performs 21 iterations in order to use all possible connection slots. We could calculate the number of available connections more accurately. It relates to the size of backend pool that is defined in src/backend/postmaster/pmchild.c:
pmchild_pools[B_BACKEND].size = 2 * (MaxConnections + max_wal_senders);
There are two points here: (1) in current implementation the test performs 11 extra iterations instead of 10 that are really needed. (2) We need to change the hardcoded value every time if the number of max connections or the number of max wal senders are changed. If we use 2 * (MaxConnections + max_wal_senders) the test becomes a bit convinent.
The patch attached.
Best regards,
Alexander Potapov
Attachments:
0001-Improve-the-test-src-test-postmaster-t-003_start_sto.patchapplication/octet-streamDownload
From e435946a545d2312d71987517936a6f61db23deb Mon Sep 17 00:00:00 2001
From: Potapov Alexander <a.potapov@postgrespro.ru>
Date: Tue, 25 Nov 2025 07:36:29 +0300
Subject: [PATCH] Improve the test src/test/postmaster/t/003_start_stop.pl
Calculate the number of iterations on base of max_connections
and max_wal_senders to be in sync with backend pool size:
2 * (max_connections + max_wal_senders)
---
src/test/postmaster/t/003_start_stop.pl | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/test/postmaster/t/003_start_stop.pl b/src/test/postmaster/t/003_start_stop.pl
index 58e7ba6cc42..92ba96a4342 100644
--- a/src/test/postmaster/t/003_start_stop.pl
+++ b/src/test/postmaster/t/003_start_stop.pl
@@ -48,10 +48,17 @@ if (!$node->raw_connect_works())
my @raw_connections = ();
-# Open a lot of TCP (or Unix domain socket) connections to use up all
-# the connection slots. Beyond a certain number (roughly 2x
-# max_connections), they will be "dead-end backends".
-for (my $i = 0; $i <= 20; $i++)
+my $max_connections = $node->safe_psql(
+ 'postgres', qq{select setting::int max_conn from pg_settings
+ where name=\$\$max_connections\$\$});
+my $max_wal_senders = $node->safe_psql(
+ 'postgres', qq{select setting::int max_conn from pg_settings
+ where name=\$\$max_wal_senders\$\$});
+my $backend_pool_size = 2 * ($max_connections + $max_wal_senders);
+
+# Open as much as possible TCP (or Unix domain socket) connections to use up all
+# the connection slots. Beyond the backend pool, they will be "dead-end backends".
+for (my $i = 0; $i < $backend_pool_size; $i++)
{
my $sock = $node->raw_connect();
--
2.40.1
On 10/12/2025 14:32, Potapov Alexander wrote:
Hello,
This is about the TAP test src/test/postmaster/t/003_start_stop.pl. The test contains a loop that performs 21 iterations in order to use all possible connection slots. We could calculate the number of available connections more accurately. It relates to the size of backend pool that is defined in src/backend/postmaster/pmchild.c:
pmchild_pools[B_BACKEND].size = 2 * (MaxConnections + max_wal_senders);
There are two points here: (1) in current implementation the test performs 11 extra iterations instead of 10 that are really needed. (2) We need to change the hardcoded value every time if the number of max connections or the number of max wal senders are changed. If we use 2 * (MaxConnections + max_wal_senders) the test becomes a bit convinent.
This seems a little pointless because the test explicitly sets
max_connectins and max_wal_senders. It's true that it currently uses
more iterations than strictly necessary, but does it matter?
- Heikki
On Wednesday, December 10, 2025 16:28 MSK, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
This seems a little pointless because the test explicitly sets
max_connectins and max_wal_senders. It's true that it currently uses
more iterations than strictly necessary, but does it matter?
Sure, currently the test works fine. But if we exactly know that the pool size is '2*(MaxConnections + max_wal_senders)' why we do not apply it to the test? The additional benefit is if someone increase the pool size for instance '2*(MaxConnections + max_wal_senders) + some_value' the test fails and indicates an issue.
-- Alexander