Обсуждение: [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
iterationsin 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
reallyneeded. (2) We need to change the hardcoded value every time if the number of max connections or the number of
maxwal senders are changed. If we  use 2 * (MaxConnections + max_wal_senders) the test becomes a bit convinent. 

The patch attached.

Best regards,
Alexander Potapov

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
iterationsin 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
reallyneeded. (2) We need to change the hardcoded value every time if the number of max connections or the number of
maxwal 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