Re: Logging of PAM Authentication Failure

On Fri, May 17, 2013 at 1:05 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Amit Langote <amitlangote09(at)gmail(dot)com> writes:
>> On Thu, May 16, 2013 at 8:01 PM, Andres Freund <andres(at)2ndquadrant(dot)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.

Can this stay in the future releases for new users of libpq to
consider using it (saving them a reconnection, however small a benefit
that is) or at least psql which is being changed to use it anyway? I
only think it makes libpq take into account a connection state that
could be used.

> 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?

Back in this thread, Horiguchi-san has posted a fix. It seems to fix
the original issue. Attaching his patch here again.

--
Amit Langote