> This code seems to me expecting for psql to send password without > closing current connnection.On the other hand psql does as > follows. > > bin/psql/startup.c: 227 >> pset.db = PQconnectdbParams(keywords, values, true); >> free(keywords); >> free(values); >> >> if (PQstatus(pset.db) == CONNECTION_BAD && >> PQconnectionNeedsPassword(pset.db) && >> password == NULL && >> pset.getPassword != TRI_NO) >> { >> PQfinish(pset.db); >> password = simple_prompt(password_prompt, 100, false); >> new_pass = true; >> } > > psql at once disconnects the current connection and reconnects > with this new password, so pam_conv_err is observed in server. > > It seems to be a kind of protocol-mimatching. Client should'nt > disconnect for password request or server should fit to what psql > does. Is this wrong?
In fact, this is the behavior with all the authentication methods that require a password. But, it is only in the case of PAM authentication that auth_failed() logs error when first connection attempt is made (without password), since the STATUS_EOF is not passed to it in that case. If we did not drop the connection (unlike what we do now) and re-attempted connection with the password added to conn, would the backend's authentication state still be waiting for the password? Can we do away without having to create a second connection? -- Amit Langote -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers