Re: [PATCH v10] GSSAPI encryption support - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [PATCH v10] GSSAPI encryption support
Date
Msg-id CAB7nPqTtJrFYy6Z5fyRiKg8DNdQ5bpCH_Qmbarhx0rSoK2RvQA@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH v10] GSSAPI encryption support  (Robbie Harwood <rharwood@redhat.com>)
Responses Re: [PATCH v10] GSSAPI encryption support  (Robbie Harwood <rharwood@redhat.com>)
List pgsql-hackers
On Fri, Apr 1, 2016 at 12:31 PM, Robbie Harwood <rharwood@redhat.com> wrote:
> - Fixed Windows build.  Thanks to Michael for patches.

This looks fine. I am not seeing build failures now.

> - Fixed buffering of large replies on the serverside.  This should fix
>   the traceback that was being seen.  The issue had to do with the
>   difference between the server and client calling conventions for the
>   _read and _write functions.

This does not fix the issue. I am still able to crash the server with
the same trace.

> - Move gss_encrypt out of the GUCs and into connection-specific logic.
>   Thanks to Tom Lane for pointing me in the right direction here.

+   /* delay processing until after AUTH_REQ_OK has been sent */
+   if (port->gss->gss_encrypt != NULL)
+       port->gss->encrypt = !strcmp(port->gss->gss_encrypt, "on");
You should use parse_bool here, because contrary to libpq, clients
should be able to use other values like "1", "0", "off", 'N', 'Y',
etc.

> - Replace writev() with two calls to _raw_write().  I'm not attached to
>   this design; if someone has a preference for allocating a buffer and
>   making a single write from that, I could be persuaded.  I don't know
>   what the performance tradeoffs are.

Relying on pqsecure_raw_write and pqsecure_raw_read is a better bet
IMO, there is already some low-level error handling.
static ConfigVariable *ProcessConfigFileInternal(GucContext context,                         bool applySettings, int
elevel);

-/*
Spurious noise.
-- 
Michael



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Timeline following for logical slots
Next
From: Craig Ringer
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Enable logical slots to follow timeline switches