On 2013-05-17 01:29:25 +0900, Amit Langote wrote: > On Fri, May 17, 2013 at 1:05 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > 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. > > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
