Re: Patch: Don't set LoadedSSL unless secure_initialize succeeds - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Patch: Don't set LoadedSSL unless secure_initialize succeeds
Date
Msg-id 2428840.1653592585@sss.pgh.pa.us
Whole thread Raw
In response to Re: Patch: Don't set LoadedSSL unless secure_initialize succeeds  (Gurjeet Singh <gurjeet@singh.im>)
Responses Re: Patch: Don't set LoadedSSL unless secure_initialize succeeds  (Gurjeet Singh <gurjeet@singh.im>)
List pgsql-hackers
Gurjeet Singh <gurjeet@singh.im> writes:
> On Mon, May 23, 2022 at 8:51 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The comments for secure_initialize() and be_tls_init() both explain
>> this already.

> The comments above secure_initialize() do, but there are no comments
> above be_tls_init(), and nothing in there attempts to explain the
> FATAL vs. LOG difference.

I was looking at the comments in libpq-be.h:

/*
 * Initialize global SSL context.
 *
 * If isServerStart is true, report any errors as FATAL (so we don't return).
 * Otherwise, log errors at LOG level and return -1 to indicate trouble,
 * preserving the old SSL state if any.  Returns 0 if OK.
 */
extern int    be_tls_init(bool isServerStart);

It isn't our usual practice to put such API comments with the extern
rather than the function definition, so maybe those comments in libpq-be.h
should be moved to their respective functions?  In any case, I'm not
excited about having three separate comments covering the same point.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: selectivity function
Next
From: "Imseih (AWS), Sami"
Date:
Subject: Re: [BUG] Panic due to incorrect missingContrecPtr after promotion