aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistproc.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2019-11-05 14:27:37 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2019-11-05 14:27:37 -0500
commit3affe76ef8227dad85b61cec769235f682132651 (patch)
tree65daa9c6bee57aa75d16c8affa3eee4a6aa3d7a4 /src/backend/access/gist/gistproc.c
parenta30531c5c8a384363d410d4027e1c1eeed76e550 (diff)
downloadpostgresql-3affe76ef8227dad85b61cec769235f682132651.tar.gz
postgresql-3affe76ef8227dad85b61cec769235f682132651.zip
Avoid logging complaints about abandoned connections when using PAM.
For a long time (since commit aed378e8d) we have had a policy to log nothing about a connection if the client disconnects when challenged for a password. This is because libpq-using clients will typically do that, and then come back for a new connection attempt once they've collected a password from their user, so that logging the abandoned connection attempt will just result in log spam. However, this did not work well for PAM authentication: the bottom-level function pam_passwd_conv_proc() was on board with it, but we logged messages at higher levels anyway, for lack of any reporting mechanism. Add a flag and tweak the logic so that the case is silent, as it is for other password-using auth mechanisms. Per complaint from Yoann La Cancellera. It's been like this for awhile, so back-patch to all supported branches. Discussion: https://postgr.es/m/CACP=ajbrFFYUrLyJBLV8=q+eNCapa1xDEyvXhMoYrNphs-xqPw@mail.gmail.com
Diffstat (limited to 'src/backend/access/gist/gistproc.c')
0 files changed, 0 insertions, 0 deletions