Re: Improve error reporting in 027_stream_regress test

On Tue, Jul 29, 2025 at 12:41:39AM -0400, Tom Lane wrote:
> Alexander Lakhin <exclusion(at)gmail(dot)com> writes:
> > The new check has failed on mamba [1], apparently because this animal is
> > too slow for pg_isready:
>
> There is something strange happening on mamba --- not sure what,
> but its cycle time for the past week has been a lot more than normal.
> I plan to power-cycle it tomorrow and see if that does anything.
> In the meantime, I'd not put a lot of stock in that failure.

As far as I can see, based on the logs, the standby seems to be
lagging behind in terms of replay. Anyway, a consistent state is
reached way before the pg_isready call is done (07:37:27 vs 08:01:50),
so pg_isready should report something as the standby is ready for
connections. And it's true that 3s would be very short in smallish
environments.

We are getting PQPING_NO_RESPONSE meaning a lack of report activity
from the postmaster. An increase in timeout may help, but the host
seems like it's facing a high workload so it's not really possible to
come with a perfect number, just an estimation. How about adding a
--timeout to pg_isready based on PGCONNECT_TIMEOUT, like in the
attached? At least that would be more in line with the other tests,
and we'd have more leverage over the timing of is_alive(). Default is
180s.
--
Michael