Horton

Re: [PATCH] Log details for client certificate failures

Jacob Champion <jchampion@timescale.com>

View thread View on postgr.es
From: Jacob Champion <jchampion@timescale.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-07-20T22:29:55Z
Lists: pgsql-hackers 
On Wed, Jul 20, 2022 at 3:15 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> guc_malloc's behavior varies depending on elevel.  It's *not*
> equivalent to palloc.

Right, sorry -- a better way for me to ask the question:

I'm currently hardcoding an elevel of ERROR on the new guc_strdup()s,
because that seems to be a common case for the check hooks. If that's
okay, is there any reason not to use palloc() semantics for
pg_clean_ascii()? (And if it's not okay, why?)

--Jacob

Commits

  1. Fix tiny memory leaks

  2. Don't reflect unescaped cert data to the logs

  3. pg_clean_ascii(): escape bytes rather than lose them

  4. Log details for client certificate failures