| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Achilleas Mantzios <achill(at)matrix(dot)gatewaynet(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pgbouncer bug? |
| Date: | 2020-08-25 10:28:58 |
| Message-ID: | 9a68d234-081e-f7e5-7da2-efc647024a18@2ndquadrant.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 2020-08-21 19:49, Achilleas Mantzios wrote:
>
> On 21/8/20 7:56 μ.μ., greigwise wrote:
>> Not sure if this is the right place to post this, but if not someone please
>> point me in the right direction.
>>
>> My issue is with pgbouncer 1.14. This does not seem to happen on 1.13.
>>
>> If I do a service pgbouncer restart, then anytime I try to connect to my
>> databases via pgbouncer, I get ERROR: no such user regardless of what user
>> I'm using. It's almost like it's not recognizing the auth_query I have
>> configured. But then if I issue a reload, then it seems to work fine and I
>> no longer get the user not found. The problem is easy enough to work around
>> as I don't restart pgbouncer all that much, but it doesn't seem like this is
>> probably the intended behavior.
>
> You may go here :
> https://github.com/pgbouncer/pgbouncer/commits/pgbouncer_1_14_0
>
> and review all commits between 1.13 and 1.14
It could be related to the SCRAM pass-through.
Greig, if you have a way to reproduce it, please file a complete bug
report on GitHub.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2020-08-25 10:36:30 | Re: Query plan prefers hash join when nested loop is much faster |
| Previous Message | iulian dragos | 2020-08-25 10:10:05 | Re: Query plan prefers hash join when nested loop is much faster |