Re: [PATCH v10] GSSAPI encryption support
От | Michael Paquier |
---|---|
Тема | Re: [PATCH v10] GSSAPI encryption support |
Дата | |
Msg-id | CAB7nPqTtJrFYy6Z5fyRiKg8DNdQ5bpCH_Qmbarhx0rSoK2RvQA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH v10] GSSAPI encryption support (Robbie Harwood <rharwood@redhat.com>) |
Ответы |
Re: [PATCH v10] GSSAPI encryption support
|
Список | 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 по дате отправления: