On 2025-04-18 Fr 7:26 PM, Tom Lane wrote:
> I wrote:
>> What I think happened here is that a previous backend hadn't exited
>> yet when we start the test, and when its report does come out,
>> connect_fails prematurely stops waiting. (In the above, evidently
>> the child process we want to wait for is 599, but we're fooled by
>> a delayed report for 25401.) So my v1 patch needs work.
>> Maybe we can make the test compare the PIDs in the "forked new client
>> backend" and "client backend exited" log messages. Stay tuned...
> Okay, this version seems more reliable.
>
+See C<log_check(...)>. CAUTION: use of either option requires that
+the server's log_min_messages be at least DEBUG2, and that no other
+client backend is launched concurrently. These requirements allow
+C<connect_fails> to wait to see the postmaster-log report of backend
+exit, without which there is a race condition as to whether we will
+see the expected backend log output.
That seems a little fragile. I can imagine test authors easily
forgetting this. Is it worth sanity checking to make sure
log_min_messages is appropriately set?
cheers
andrew
>
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
