Re: Logging of PAM Authentication Failure

Andres Freund <andres(at)2ndquadrant(dot)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.

So, while I wouldn't have objected to this if it'd been included in the
original design for PQconnectPoll-style connections, it's really unclear
that it's worth the work to add it now.

regards, tom lane