Hello, Is it right that it is only in the case a password prompt is needed that a new connection is created after dropping the just-failed connection? I created a patch which enables it to use the existing connection in such a case (unlike what we currently do). It modifies connectDBComplete() and PQconnectPoll() to also include states pertaining to password being accepted from the user. That is, the state machine in PQconnectPoll() is further extended to include a connection state called CONNECTION_ASKING_PASSWORD which is entered when server sends AUTH_REQ_MD5 or AUTH_REQ_PASSWORD auth requests. These two request types require a password to be entered by the user. There is a new PostgresPollingStatusType value called PGRES_POLLING_WAITING_PASSWORD which is the polling status while a password is being entered by the user.
When user enters the password the PQconnectPoll() continues forward in CONNECTION_ASKING_PASSWORD wherein it sends the password to the server (by calling pg_fe_sendauth() and this time with a potentially correct password) and later goes back to CONNECTION_AWAITING_RESPONSE to read server's response to the password just entered where it either receives authorization OK or error response thus completing the connection start-up process. The backend waits for the password until authentication timeout happens in which case the client can not send the password anymore since the backend has exited due to authentication timeout. I wonder if this is one of the reasons why this has not already been implemented? Comments? On Tue, May 14, 2013 at 11:22 AM, Amit Langote <amitlangot...@gmail.com> wrote: >> Well, if we are allowed to use a bit ugry way, the attached patch >> seems to cope with this issue. As far as I can see there's no >> problem since pg_fe_sendauth() refueses to send empty password. >> >> Any suggestions? > > That seems to do the trick. This probably solves the problem that I > originally posted. > >> Sorry, I've read there incorrectly. I had understood the code >> after sendAuthRequest in pam_passwd_conv_proc but it is used >> indeed. > > Though, I am still not sure why we drop the existing connection and > start all over again but now with the newly entered password. This > kind of seems to leave the protocol state machine (as in > PQconnectPoll() ) halfway (after pg_fe_sendauth() failed) in the first > connection attempt for the auth requests requiring the password (or > others, too?). Although, sticking to this design may have to do with > the problems of doing otherwise that I am unaware of. > > > -- > Amit Langote -- Amit Langote
psql-use-existing-conn-passwd.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
