On Thu, May 26, 2022 at 4:13 PM Tom Lane wrote:
> Gurjeet Singh writes:
> > On Thu, May 26, 2022 at 12:16 PM Tom Lane wrote:
> >> 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
On Thu, May 26, 2022 at 2:40 PM Tom Lane wrote:
>
> Robert Haas writes:
> > I think you're overreacting to a behavior that isn't really very surprising.
>
> > If we don't initialize SSL the first time, we don't have a working SSL
> > stack. If we didn't choose to die at that point, we'd be
Gurjeet Singh writes:
> On Thu, May 26, 2022 at 12:16 PM Tom Lane wrote:
>> 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.
> By 3 locations, I suppose you're
Robert Haas writes:
> I think you're overreacting to a behavior that isn't really very surprising.
> If we don't initialize SSL the first time, we don't have a working SSL
> stack. If we didn't choose to die at that point, we'd be starting up a
> server that could not accept any SSL connections.
On Thu, May 26, 2022 at 1:00 PM Robert Haas wrote:
>
> On Thu, May 26, 2022 at 1:05 AM Gurjeet Singh wrote:
> > There's an symmetry, almost a diametric opposition, between how SSL
I meant "an asymmetry".
> > initialization error is treated when it occurs during server startup,
> > versus when
On Thu, May 26, 2022 at 12:16 PM Tom Lane wrote:
> Gurjeet Singh writes:
> > On Mon, May 23, 2022 at 8:51 PM Tom Lane 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
> >
On Thu, May 26, 2022 at 1:05 AM Gurjeet Singh wrote:
> There's an symmetry, almost a diametric opposition, between how SSL
> initialization error is treated when it occurs during server startup,
> versus when the error occurs during a reload/SIGHUP. During startup an
> error in SSL initialization
Gurjeet Singh writes:
> On Mon, May 23, 2022 at 8:51 PM Tom Lane 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
On Wed, May 25, 2022 at 10:05 PM Gurjeet Singh wrote:
> I have added a comment to be_tls_init(), which I hope explains this
> difference in treatment of errors. I have also added comments to
> be_tls_init(), explaining why we don't destroy/free the global
> SSL_context variable in case of an
On Mon, May 23, 2022 at 8:51 PM Tom Lane wrote:
>
> Daniel Gustafsson writes:
> >> On 22 May 2022, at 08:41, Gurjeet Singh wrote:
> >> The initialization in PostmasterMain() blindly turns on LoadedSSL,
> >> irrespective of the outcome of secure_initialize().
>
> > This call is invoked with
On Sun, May 22, 2022 at 12:17 AM Daniel Gustafsson wrote:
> > On 22 May 2022, at 08:41, Gurjeet Singh wrote:
>
> > The initialization in PostmasterMain() blindly turns on LoadedSSL,
> > irrespective of the outcome of secure_initialize().
>
> This call is invoked with isServerStart set to true so
Daniel Gustafsson writes:
>> On 22 May 2022, at 08:41, Gurjeet Singh wrote:
>> The initialization in PostmasterMain() blindly turns on LoadedSSL,
>> irrespective of the outcome of secure_initialize().
> This call is invoked with isServerStart set to true so any error in
> secure_initialize
On Sun, May 22, 2022 at 09:17:37AM +0200, Daniel Gustafsson wrote:
> This call is invoked with isServerStart set to true so any error in
> secure_initialize should error out with ereport FATAL (in be_tls_init()).
> That
> could be explained in a comment though, which is currently isn't.
All the
> On 22 May 2022, at 08:41, Gurjeet Singh wrote:
> The initialization in PostmasterMain() blindly turns on LoadedSSL,
> irrespective of the outcome of secure_initialize().
This call is invoked with isServerStart set to true so any error in
secure_initialize should error out with ereport FATAL
The initialization in PostmasterMain() blindly turns on LoadedSSL,
irrespective of the outcome of secure_initialize(). I don't think
that's how it should behave, primarily because of the pattern followed
by the other places that call secure_initialize().
This patch makes PostmasterMain() behave
15 matches
Mail list logo
