On 04/12/2018 07:37 AM, armand pirvu wrote:
>
>> On Apr 12, 2018, at 9:28 AM, Adrian Klaver <adrian.klaver@aklaver.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.klaver@aklaver.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
connectionswise
> As a workaround for this very specific set of processes, until things get back in line so to speak, do you think from
thedevweb2004 (where processing is done) to devdb2004 (where the postgres database resides), should I just go from md5
totrusted ?
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.klaver@aklaver.com
