Andrew Dunstan wrote:
> >This seems reasonable behavior when prompting for a password from the
> >user, since that's going to take a lot of time anyway. I'm not sure
> >whether libpq should try to excavate a password from ~/.pgpass in
> >advance of being told by the server that one is needed.
> >
> >An ideal solution might be to read ~/.pgpass during the bit of code that
> >handles a password challenge from the server, rather than in the "outer
> >loop". Not having looked at the libpq code recently, I have no idea how
> >painful that would be to do.
> >
> >
>
> Actually, it looks to me like the cause is some code in psql/startup.c
> which keeps trying to make a connection while it gets
> PQnoPasswordSupplied. libpq seemed to work just fine, picking up pgpass
> before a connection was attempted.
>
> My only real concern is that when you turn on log_connections the traces
> are confusing - from the user's perspective there is only one
> connection, and there are two mentioned in the log, one of which doesn't
> have a correspondingly logged disconnect. Maybe worth a mention in the docs?
I turned on passwords and did see duplicate connections:
LOG: connection received: host=[local]LOG: connection received: host=[local]LOG: connection authorized:
user=postgresdatabase=testLOG: disconnection: session time: 0:00:00.61 user=postgres database=test host=[local]
Basically psql first tries with no password, then when it fails asking
for a password, it prompts for one and connects. You will notice only
one "authorized:" message. I think that is the real "connection" line,
rather than the "recevied" lines. Not sure how we can improve this. We
could print an "authorization failed" message. Would that help, or just
be overkill?
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
