> On Apr 12, 2018, at 9:48 AM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
>
> 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
fromthe devweb2004 (where processing is done) to devdb2004 (where the postgres database resides), should I just go from
md5to 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.klaver@aklaver.com
Will do so and report back
Many thanks
Armand
