On Thu, Mar 06, 2025 at 02:25:07PM -0800, Jacob Champion wrote:
> On Wed, Mar 5, 2025 at 8:08 PM Michael Paquier <michael@paquier.xyz> wrote:
>> + WHERE state = 'starting' and wait_event = 'init-pre-auth';});
>
> Did you have thoughts on expanding the check to backend_type [1]?
>
>> + # Give up. The output of the last attempt is logged by query(),
>> + # so no need to do anything here.
>> + return 0;
>
> One of my primary complaints about the poll_query_until()
> implementation is that "giving up" in this case means continuing to
> run pieces of the test that have no business running after a timeout,
> and increasing the log noise after a failure. I'm not sure how loudly
> to complain in this particular case, since I know we use it
> elsewhere...
Indeed. The existing poll_query_until() is a bit more reliable in
terms of error handling, even with a very low PG_TEST_TIMEOUT_DEFAULT.
A second thing that was bugging me on a second lookup this morning is
how we should handle error cases. A background psql process depends
on what the caller defines for ON_ERROR_STOP. In the case of this
test, we're OK to fail immediately because we expect the queries to
always work. I'm not sure if this is fine by default, especially if
callers of this routine expect to have the same properties as
poll_query_until() in Cluster.pm. They would not, because a
BackgroundPsql is an entire different object, except if given options
when staring psql to act like that.
I have applied the simplest patch for now, to silence the failures in
the CI, and included your suggestion to add a check on the
backend_type for the extra safety it offers.
I'd like the addition of the poll_query_until() in the long-term, but
I'm really not sure if the semantics would be right this way under a
background psql. In the auth 007 test, they would be OK, but it could
be surprising if we have other callers that begin relying on it.
--
Michael
