On 2013-05-17 01:29:25 +0900, Amit Langote wrote:
> On Fri, May 17, 2013 at 1:05 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Amit Langote <amitlangote09@gmail.com> writes:
> >> On Thu, May 16, 2013 at 8:01 PM, Andres Freund <andres@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.
>
> 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.
Which basically is an API & ABI break since its not handled in existing
callers. So you would need to make it conditional. At that point the
complexity really doesn't seem warranted.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services