Re: Patch: Don't set LoadedSSL unless secure_initialize succeeds

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gurjeet Singh <gurjeet(at)singh(dot)im>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch: Don't set LoadedSSL unless secure_initialize succeeds
Date: 2022-05-26 19:16:25
Message-ID: 2428840.1653592585@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gurjeet Singh <gurjeet(at)singh(dot)im> writes:
> On Mon, May 23, 2022 at 8:51 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Imseih (AWS), Sami 2022-05-26 19:57:41 Re: [BUG] Panic due to incorrect missingContrecPtr after promotion
Previous Message Tom Lane 2022-05-26 19:10:21 Re: selectivity function