Re: [PATCH] Log details for client certificate failures

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Jacob Champion <jchampion(at)timescale(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Log details for client certificate failures
Date: 2022-07-11 13:09:19
Message-ID: 2ef20161-e99d-a6ea-a36d-577843a2daae@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 08.07.22 20:39, Jacob Champion wrote:
> I also added an optional 0002 that bubbles the error info up to the
> final ereport(ERROR), using errdetail() and errhint(). I can squash it
> into 0001 if you like it, or drop it if you don't. (This approach
> could be adapted to the client, too.)

I squashed those two together. I also adjusted the error message a bit
more for project style. (We can put both lines into detail.)

I had to read up on this "ex_data" API. Interesting. But I'm wondering
a bit about how the life cycle of these objects is managed. What
happens if the allocated error string is deallocated before its
containing object? Or vice versa? How do we ensure we don't
accidentally reuse the error string when the code runs again? (I guess
currently it can't?) Maybe we should avoid this and just put the
errdetail itself into a static variable that we unset once the message
is printed?

Attachment Content-Type Size
v5-0001-Log-details-for-client-certificate-failures.patch text/plain 16.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2022-07-11 13:16:30 Re: pg15b2: large objects lost on upgrade
Previous Message Matthias van de Meent 2022-07-11 13:07:47 Re: Commitfest Update