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 |
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 |