From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jacob Champion <jchampion@timescale.com>
cc: Andres Freund <andres@anarazel.de>,
        Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
        "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: [PATCH] Log details for client certificate failures
In-reply-to: 
 <CAAWbhmhGOh_1C6x1A8K5hsMuSeOF5hxQ4ZMGkFhqmVTZ0otzRQ@mail.gmail.com>
References: <2878aee8-a4a6-8078-9740-efe90fcf8328@timescale.com>
 <20220715211914.c5oasfknx2njndov@awork3.anarazel.de>
 <1d3d62a0-2d7f-4592-bf76-ba59a77e61cc@timescale.com>
 <20220715234519.7o4mlpxapmqmv6p7@awork3.anarazel.de>
 <CAAWbhmiH2dPpRUnpS6pe9Fge--gj_az4ra2AJO1JvTKeiFuAug@mail.gmail.com>
 <20220719161432.qha3s76vyc6k4v5m@awork3.anarazel.de>
 <c0eca922-59db-ad5c-193f-09bc36b92468@timescale.com>
 <1212792.1658248783@sss.pgh.pa.us>
 <20220719170954.nshvmok3tymxdpl3@awork3.anarazel.de>
 <CAAWbhmiVZgfAUc=BuahotfHokWuJXLD6KQs8gYVvp_twFgQ-xg@mail.gmail.com>
 <20220719223823.pj4z36ce3zb27qdb@alap3.anarazel.de>
 <CAAWbhmhGOh_1C6x1A8K5hsMuSeOF5hxQ4ZMGkFhqmVTZ0otzRQ@mail.gmail.com>
Comments: In-reply-to Jacob Champion <jchampion@timescale.com>
	message dated "Wed, 20 Jul 2022 15:11:10 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2007343.1658355307.1@sss.pgh.pa.us>
Date: Wed, 20 Jul 2022 18:15:07 -0400
Message-ID: <2007344.1658355307@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2007344.1658355307%40sss.pgh.pa.us>
Precedence: bulk

Jacob Champion <jchampion@timescale.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