| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pgsql: Log details for client certificate failures |
| Date: | 2022-07-16 13:57:12 |
| Message-ID: | 3820525.1657979832@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
Justin Pryzby <pryzby(at)telsasoft(dot)com> writes:
> On Sat, Jul 16, 2022 at 01:57:25PM +0200, Peter Eisentraut wrote:
>> Isn't the cfbot using the same thing?
> It's using the same thing, so I suppose the failure is intermittent.
> It failed for me just now: https://cirrus-ci.com/task/6502388730167296
It looks like a timing problem, which you'd probably never reproduce
on an unloaded development system. On the presumably-busy CI hosts,
I think we're managing to examine the log file before the backend has
written the log entry.
Can we rejigger the backend so that the log entry is written before
we shove the failure response out to the client? Maybe not given the
implementation technology. In that case the alternatives seem to be
(1) insert a delay in the log_like checks (ugh) or
(2) abandon attempting to test this particular behavior.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-07-16 14:45:29 | Re: pgsql: Log details for client certificate failures |
| Previous Message | Peter Eisentraut | 2022-07-16 13:48:12 | pgsql: Attempt to fix compiler warning on old compiler |