On Thu, Mar 06, 2025 at 02:25:07PM -0800, Jacob Champion wrote: > On Wed, Mar 5, 2025 at 8:08 PM Michael Paquier <mich...@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
signature.asc
Description: PGP signature
