Re: Improve error reporting in 027_stream_regress test

Hi,

Thank you all for reporting the failure and sharing your inputs!

On Tue, 29 Jul 2025 at 09:07, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> 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.

I think it makes sense to add this timeout, as it would be more in
line with the other tests like you said.

--
Regards,
Nazir Bilal Yavuz
Microsoft