Horton

Re: disabled SSL log_like tests

Tom Lane <tgl@sss.pgh.pa.us>

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

Setting log_min_messages is not so easily forgotten, because
connect_fails will just hang until timeout if you didn't.

I'm more worried about the "no other backend" requirement.
I think v2 is reasonably proof against that, but whether it's
sufficiently bulletproof to withstand the buildfarm environment
remains to be seen.  I wish there were a better way to
determine the backend PID for a failed connection...

			regards, tom lane

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.