Amit Langote <amitlangot...@gmail.com> writes:
> On Thu, May 16, 2013 at 8:01 PM, Andres Freund <and...@2ndquadrant.com> wrote:
>> I unfortunately have to say I don't really see the point of this. The
>> cost of the additional connection attempt is rather low and we have to
>> deal with the superflous attempts anyway since there will be old libpqs
>> around for years. Why is this worth the effort?
> While full connection sequence (with proper authentication exchanges)
> appears to go smoothly for other cases (authentication methods), it
> doesn't quite in this case probably because accounting for such a case
> was not considered to be as important. But while investigating about
> the PAM issue (original subject of this thread), it turned out that
> the occurrence of that minor issue was due to this behavior in libpq.
I have to agree with Andres that it's not clear this is a reasonable
fix. To get rid of extra reconnections this way will require not merely
upgrading libpq, but upgrading every single application that uses libpq
and is capable of prompting its user for a password. The odds are
pretty good that that won't ever happen.
The real complaint here is that the server-side PAM auth code path is
losing the information that the client chose to disconnect rather than
offer a password, and thus logging a message that we could do without.
What's wrong with just fixing that?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
