| 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-18 23:26:32 |
| Message-ID: | 2915194.1745018792@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| v2-fix-connect_fails-races.patch | text/x-diff | 10.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Yurii Rashkovskii | 2025-04-19 01:18:21 | SQL function to access to `creating_extension` |
| Previous Message | Tom Lane | 2025-04-18 22:26:35 | Re: disabled SSL log_like tests |