Re: [HACKERS] Error-like LOG when connecting with SSL for passwordauthentication - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: [HACKERS] Error-like LOG when connecting with SSL for passwordauthentication
Date
Msg-id 431eb445-82b7-25bf-54ee-52b7e889326a@iki.fi
Whole thread Raw
In response to Re: [HACKERS] Error-like LOG when connecting with SSL for password authentication  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] Error-like LOG when connecting with SSL for password authentication
List pgsql-hackers
On 05/24/2017 05:29 PM, Michael Paquier wrote:
> Attached is an updated patch.

Thanks, I've pushed the backend read part of this patch. That's enough 
to fix the original complaint with password authentication. I think the 
rest was a bit dubious, and I'm hesitant to commit that (or at least to 
backport):

* Backend write: you wouldn't really expect a client to disconnect, 
while the backend is trying to send something to it. You'll get an error 
in the non-SSL case too, although I guess the error message would be 
different.

* Frontend read: pqReadData has this, after calling pqsecure_read:

>     /*
>      * A return value of 0 could mean just that no data is now available, or
>      * it could mean EOF --- that is, the server has closed the connection.
>      * Since we have the socket in nonblock mode, the only way to tell the
>      * difference is to see if select() is saying that the file is ready.
>      * Grumble.  Fortunately, we don't expect this path to be taken much,
>      * since in normal practice we should not be trying to read data unless
>      * the file selected for reading already.
>      *
>      * In SSL mode it's even worse: SSL_read() could say WANT_READ and then
>      * data could arrive before we make the pqReadReady() test, but the second
>      * SSL_read() could still say WANT_READ because the data received was not
>      * a complete SSL record.  So we must play dumb and assume there is more
>      * data, relying on the SSL layer to detect true EOF.
>      */
>
> #ifdef USE_SSL
>     if (conn->ssl_in_use)
>         return 0;
> #endif

* Frontend write: Same as in the backend, I think having the server 
disconnect while you're trying to send to it is not expected. Not sure 
if the error message is here again different, but seems best to just 
leave it alone.

- Heikki



pgsql-hackers by date:

Previous
From: Ashutosh Sharma
Date:
Subject: Re: [HACKERS] hash index on unlogged tables doesn't behave as expected
Next
From: Marina Polyakova
Date:
Subject: Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors