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: | Raw Message | Whole Thread | 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 |