Re: [PATCH] Log details for client certificate failures - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [PATCH] Log details for client certificate failures
Date
Msg-id 2ef20161-e99d-a6ea-a36d-577843a2daae@enterprisedb.com
Whole thread Raw
In response to Re: [PATCH] Log details for client certificate failures  (Jacob Champion <jchampion@timescale.com>)
Responses Re: [PATCH] Log details for client certificate failures
List 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

pgsql-hackers by date:

Previous
From: Matthias van de Meent
Date:
Subject: Re: Commitfest Update
Next
From: Robert Haas
Date:
Subject: Re: pg15b2: large objects lost on upgrade