Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix a bunch of issues around auth_user #393

Open
wants to merge 3 commits into
base: master
from

Conversation

@pinaraf
Copy link

pinaraf commented Jun 14, 2019

When switching a pgbouncer configuration from using userlist.txt files to using auth_query/auth_user, I encountered several issues, all fixed in this PR.

  1. the wait_start field is not always initialized when using auth_query, displaying weird random stats
    Example:
2019-06-14 15:41:07.500 26350 LOG stats: 0 xacts/s, 0 queries/s, in 0 B/s, out 9 B/s, xact 0 us, query 0 us, wait 183224844063 us
  1. the global auth_user configuration variable is mis-handled: it has to be defined before the databases in the .ini file, it can not be defined using the pgbouncer shell unless a reload is applied… This is fixed here by simply not using it from parse_database and instead having it be checked when needed.

  2. when removing users from userlist.txt, the corresponding objects are not removed from memory. Instead, their passwords are emptied. This prevents auth_query from being called since the if is valid only for non-existing users.

close #391

Delay initialization of db->auth_user until it is really needed.
This way, only the latest, really wanted cf_auth_user value is considered
…ord through auth_query

This fixes the case where you are using a filled-in userlist.txt file, but
want to switch to auth_query without restarting pgbouncer.
Previous behavior:
- cleaning userlist.txt removed the passwords (replaced by '\0')
- the auth_query is not started because the users still existed
- login failed
New behavior:
- if the password is empty, start the auth_query
- when auth_query answer arrives, fill it back in user->passwd if it already exists
petere added a commit that referenced this pull request Jul 31, 2019
When using auth_user, the transition to the CL_WAITING_LOGIN state
would not initialize the client->wait_start field.  This would either
lead to garbage values being recorded, or under assertions enabled it
would crash in activate_client().

(test_auth_user was actually reproducing this problem, but a crash
requires assertions enabled and new memory being all zero, so it was
difficult to catch it.)

Author: @pinaraf

see #393
@petere

This comment has been minimized.

Copy link
Contributor

petere commented Jul 31, 2019

I have committed a fix for the first issue, but with the code a bit different. I'll continue to work through the other issues.

@pinaraf

This comment has been minimized.

Copy link
Author

pinaraf commented Oct 23, 2019

Hello @petere

Any news regarding merging fixes for the two other issues? To be honest, the total_wait_time was no the one bothering us the most…

Regards

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.