Re: [PATCH] Log details for client certificate failures
Peter Eisentraut <peter.eisentraut@enterprisedb.com>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Jacob Champion <jchampion@timescale.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-07-11T13:09:19Z
Lists: pgsql-hackers
Attachments
- v5-0001-Log-details-for-client-certificate-failures.patch (text/plain) patch v5-0001
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?
Commits
-
Fix tiny memory leaks
- a9d58bfe8a3a 16.0 landed
-
Don't reflect unescaped cert data to the logs
- 257eb57b50f7 16.0 landed
-
pg_clean_ascii(): escape bytes rather than lose them
- 45b1a67a0fcb 16.0 landed
-
Log details for client certificate failures
- 3a0e385048ad 16.0 landed