From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
        pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Log details for client certificate failures
In-reply-to: <20220716121723.GW18011@telsasoft.com>
References: <E1oCNLk-000LCH-Af@gemulon.postgresql.org>
 <20220716113752.GU18011@telsasoft.com>
 <48b78358-70d8-8de5-02ea-669c4051e4ba@enterprisedb.com>
 <20220716121723.GW18011@telsasoft.com>
Comments: In-reply-to Justin Pryzby <pryzby@telsasoft.com>
	message dated "Sat, 16 Jul 2022 07:17:23 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3820524.1657979832.1@sss.pgh.pa.us>
Date: Sat, 16 Jul 2022 09:57:12 -0400
Message-ID: <3820525.1657979832@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3820525.1657979832%40sss.pgh.pa.us>
Precedence: bulk

Justin Pryzby <pryzby@telsasoft.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