Random 038_walsnd_shutdown_timeout.pl failure on goldfish

Hi hackers,

An animal goldfish failed subscription/038_walsnd_shutdown_timeout [1].

IIUC, this failure occurs because the timeout associated with the background psql
session $sub_session expires. The failure can be reproduced by adding a long sleep
after the background session has been created but before it is used again, for
example:

```diff
--- a/src/test/subscription/t/038_walsnd_shutdown_timeout.pl
+++ b/src/test/subscription/t/038_walsnd_shutdown_timeout.pl
@@ -152,6 +152,8 @@ $node_publisher->backup(
'dbname=postgres', '--write-recovery-conf'
]);

+sleep(180);
+
```

BackgroundPsql uses an IPC::Run::Timer [2] to implement a timeout. The timer is
passed to IPC::Run::start() when the background psql process is launched, and
the default timeout interval is 180 seconds. Unless explicitly restarted,
the timer continues to run for the lifetime of the background session, rather
than starting for each query.

According to the test code and logs, $sub_session had already been created before
a new backup was taken from the publisher. The base backup itself took about
100 seconds, and approximately 172 seconds elapsed between two uses of
$sub_session->query_safe(). As a result, by the time the later query was issued,
almost all of the background session's timeout interval had already been consumed,
and IPC::Run reported a timeout shortly afterwards.

I have not determined why the base backup took unusually long on this machine,
but I don't think the duration of unrelated operations should consume the timeout
budget of a later background query.

BackgroundPsql::set_query_timer_restart() causes the timer to be restarted before
each query. The attached patch uses it for $sub_session, so that each background
query gets a fresh timeout interval.

How do you feel?

[1]: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=goldfish&dt=2026-07-31%2018%3A15%3A06
[2]: https://metacpan.org/pod/IPC::Run::Timer

Best regards,
Hayato Kuroda
FUJITSU LIMITED