The t/unavailable-server.t's subtest Direct connection timed out' uses 192.0.2.1 host in a hope the TCP connection will time out. But this is not true in properly configured network because 192.0.2.0/24 destination should be blocked by routers and properly blocked means to return in ICMP error message and that means an operating system will return an error to the process very quickly within the timeout interval. Then the test fails like this:
t/random.t .............. ok
DBI connect('dbname=fake;host=192.0.2.1','fakeuser',...) failed: could not connect to server: No route to host
Is the server running on host "192.0.2.1" and accepting
TCP/IP connections on port 5432? at t/unavailable-server.t line 43.
# Failed test 'Direct connection timed out'
# at t/unavailable-server.t line 45.
# Pausing up to 10 seconds to test timeout...
DBI connect('dbname=fake;host=192.0.2.1','fakeuser',...) failed: could not connect to server: No route to host
Is the server running on host "192.0.2.1" and accepting
TCP/IP connections on port 5432? at /tmp/loop_over_bdir-31667-GGRLsf/DBD-Multi-1.01-0/blib/lib/DBD/Multi.pm line 441.
DBI connect('dbname=fake;host=192.0.2.1','fakeuser',...) failed: could not connect to server: No route to host
Is the server running on host "192.0.2.1" and accepting
TCP/IP connections on port 5432? at /tmp/loop_over_bdir-31667-GGRLsf/DBD-Multi-1.01-0/blib/lib/DBD/Multi.pm line 441.
DBI connect('dbname=fake;host=192.0.2.1','fakeuser',...) failed: could not connect to server: No route to host
Is the server running on host "192.0.2.1" and accepting
TCP/IP connections on port 5432? at /tmp/loop_over_bdir-31667-GGRLsf/DBD-Multi-1.01-0/blib/lib/DBD/Multi.pm line 441.
# Looks like you failed 1 test of 7.
t/unavailable-server.t ..
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/7 subtests
If you want to test a timeout, you should start a TCP server on localhost, let the test connect to it, but does not provide any PostgreSQL protocol response from the server (or even do not accept the TCP connection, just keep it in conneciton backlog).
The t/unavailable-server.t's subtest Direct connection timed out' uses 192.0.2.1 host in a hope the TCP connection will time out. But this is not true in properly configured network because 192.0.2.0/24 destination should be blocked by routers and properly blocked means to return in ICMP error message and that means an operating system will return an error to the process very quickly within the timeout interval. Then the test fails like this:
If you want to test a timeout, you should start a TCP server on localhost, let the test connect to it, but does not provide any PostgreSQL protocol response from the server (or even do not accept the TCP connection, just keep it in conneciton backlog).