Feedback-ID: i131946ab:Fastmail
Message-ID: <9dbf3db1-6894-321c-af49-e122a7cd47cb@enterprisedb.com>
Date: Sat, 1 Oct 2022 12:52:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.3.0
Subject: Re: [PATCH] Log details for client certificate failures
Content-Language: en-US
To: Masahiko Sawada <sawada.mshk@gmail.com>,
 Jacob Champion <jchampion@timescale.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
References: <2878aee8-a4a6-8078-9740-efe90fcf8328@timescale.com>
 <20220719223823.pj4z36ce3zb27qdb@alap3.anarazel.de>
 <CAAWbhmhGOh_1C6x1A8K5hsMuSeOF5hxQ4ZMGkFhqmVTZ0otzRQ@mail.gmail.com>
 <2007344.1658355307@sss.pgh.pa.us>
 <CAAWbhmj3q=RbGwurus5V3Dh7u5q9msVmQ=61mZptoWxBBuWJug@mail.gmail.com>
 <2012342.1658356951@sss.pgh.pa.us>
 <CAAWbhmgsvHrH9wLU2kYc3pOi1KSenHSLAHBbCVmmddW6-mc_=w@mail.gmail.com>
 <CAAWbhmisCf9qzPhQamYUobJvC7r1A1sCeZWJZpDBWh+FHJ=RGQ@mail.gmail.com>
 <CAAWbhmhrEd2wcnmf4KxAXyx+Rj7nm+oiaxQSjfAzC5qU4_e8ng@mail.gmail.com>
 <6f9eff5c-ecc6-c0d5-df8e-8df9e2f10534@enterprisedb.com>
 <CAD21AoBmFNy9MPfA0UUbMubQqH3AaK5U3mrv6pSeWrwCk3LJ8g@mail.gmail.com>
 <CAAWbhmhHP60pFtjiwn_oc==P+X7R53J2Wqg=Fxb85EjMExHPFA@mail.gmail.com>
 <CAD21AoDpBrbuSCsK=wgjJNg=A_L0Sx7pimZ24QL9SruxRZS=BA@mail.gmail.com>
 <CAAWbhmjVzvEujjZCRbD2+R=9aT36Dq2oKgAvp0FiMNVoLY6VVQ@mail.gmail.com>
 <CAD21AoDuNacZPAWENd4TQDio0dBNBiPHmMaE8477Xh5Gu8J1AA@mail.gmail.com>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
In-Reply-To: 
 <CAD21AoDuNacZPAWENd4TQDio0dBNBiPHmMaE8477Xh5Gu8J1AA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/9dbf3db1-6894-321c-af49-e122a7cd47cb%40enterprisedb.com>
Precedence: bulk

On 29.09.22 06:52, Masahiko Sawada wrote:
> While this seems a future-proof idea, I wonder if it might be overkill
> since we don't need to worry about accumulation of leaked memory in
> this case. Given that only check_cluter_name is the case where we
> found a small memory leak, I think it's adequate to fix it.
> 
> Fixing this issue suppresses the valgrind's complaint but since the
> boot value of cluster_name is "" the memory leak we can avoid is only
> 1 byte.

I have committed this.  I think it's better to keep the code locally 
robust and not to have to rely on complex analysis of how GUC memory 
management works.