From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
Subject: | Re: disabled SSL log_like tests |
Date: | 2025-04-19 14:31:47 |
Message-ID: | 3014850.1745073107@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-04-19 16:17:24 | What's our minimum supported Python version? |
Previous Message | Mircea Cadariu | 2025-04-19 14:28:35 | Re: Metadata and record block access stats for indexes |