Re: [PATCH] Log details for client certificate failures

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jacob Champion <jchampion(at)timescale(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Log details for client certificate failures
Date: 2022-07-20 22:15:07
Message-ID: 2007344.1658355307@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jacob Champion <jchampion(at)timescale(dot)com> writes:
> The guc_strdup() approach really reduces the amount of code, so that's
> what I did in v3. I'm not following why we need to return NULL on
> failure, though -- both palloc() and guc_malloc() ERROR on failure, so
> is it okay to keep those semantics the same?

guc_malloc's behavior varies depending on elevel. It's *not*
equivalent to palloc.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2022-07-20 22:29:55 Re: [PATCH] Log details for client certificate failures
Previous Message Jacob Champion 2022-07-20 22:11:10 Re: [PATCH] Log details for client certificate failures