On Fri, May 17, 2013 at 1:46 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@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
