Horton

Re: disabled SSL log_like tests

Andrew Dunstan <andrew@dunslane.net>

View thread View on postgr.es
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>, Jacob Champion <jacob.champion@enterprisedb.com>
Date: 2025-04-19T11:47:26Z
Lists: pgsql-hackers 
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

Commits

  1. Skip RSA-PSS ssl test when using LibreSSL.

  2. Ooops ... add required configure support.

  3. Hack one ssl test case to pass with current LibreSSL.

  4. Centralize ssl tests' check for whether we're using LibreSSL.

  5. Re-enable SSL connect_fails tests, and fix related race conditions.

  6. Disable unstable test cases in src/test/ssl/t/001_ssltests.pl.