On Fri, May 17, 2013 at 1:46 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andres Freund <and...@2ndquadrant.com> writes: >> On 2013-05-17 01:29:25 +0900, Amit Langote wrote: >>> 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. > > Yeah, there would need to be a way for the caller to indicate that it's > prepared to handle this new connection state; else you risk actively > breaking existing code that doesn't know it needs to do something here. > > Another point worth considering is that, if you assume that what's going > to happen is manual entry of a password (probably requiring at least a > couple of seconds), the actual benefit of avoiding a second fork() is > really completely negligible. It could even be argued that the benefit > is negative, since we're tying up a postmaster child process slot that > might be better used for something else.
I agree it's a pretty valid point. We'd better just fix the original issue and leave it to that. :) -- 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
