Re: authentication failure

On 04/12/2018 07:37 AM, armand pirvu wrote:
>
>> On Apr 12, 2018, at 9:28 AM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> wrote:
>>
>> On 04/12/2018 07:15 AM, armand pirvu wrote:
>>
>>>>
>>>>
>>> Sorry for the double posting but could it be from
>>> #authentication_timeout = 1min# 1s-600s
>>
>> From you previous post:
>>
>> "It is almost like the authnetication stops working for whatever reason"
>>
>> So to be clear the initial connections in the process go through, but at some point they start failing. Is that correct?
>>
>> The timeout could be an issue. It would helpful to also see what max_connections setting is.
>>
>>> So if the server gets a bit oveloaded this could play a role ?
>>
>>
>> --
>> Adrian Klaver
>> adrian(dot)klaver(at)aklaver(dot)com
>
>
> Yes correct initially they go through but at some point they start failing
> Max_connections is set to 200 on the postgres server, but I did not notice any message about being maxed out connections wise
> As a workaround for this very specific set of processes, until things get back in line so to speak, do you think from the devweb2004 (where processing is done) to devdb2004 (where the postgres database resides), should I just go from md5 to trusted ?

I would be inclined to raise the authentication_timeout first before
setting the auth method to trust.

I would also set the below.:

https://www.postgresql.org/docs/10/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHAT

log_connections (boolean)
Causes each attempted connection to the server to be logged, as well as
successful completion of client authentication. Only superusers can
change this parameter at session start, and it cannot be changed at all
within a session. The default is off.

log_disconnections (boolean)

That will give you a better idea of what is going on connection wise.

>
>
>
>
>
>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com