Ok, so we had a retry decorator around a group of ORM calls. This seems to
be the issue. If we wrap each call instead, things are much better.
I wonder if the transaction rollback is causing issues.
Karim
On Monday, 2 March 2020 10:28:41 UTC-8, Karim Gillani wrote:
>
> Sadly we are
more promising.
Very strange and the mystery continues..
Karim
On Thursday, 27 February 2020 14:30:32 UTC-8, Karim Gillani wrote:
>
> Latest update:
>
> 1. Psycopyg2 works with connect_timeout - Direct SQL call
> 2. sqlalchemy works with connect_timeout (Direct SQL call no
sql+psycopg2://scott:tiger@localhost/test?connect_timeout=2")
>
> however, in the above case the timeout is passed as a string "2" and not
> an integer, which may interfere with it working, im not sure. the
> separate connect_args approach is safer.
>
>
>
> On
pg2 above proves that it solves your connection
> issue.
>
>
> On Wed, Feb 26, 2020, at 11:19 AM, Karim Gillani wrote:
>
> Thanks. I don't believe this is a Red Hat issue as much as a
> configuration issue. This is because I can replicate the issue using PSQL
> a
February 26, 2020 at 11:19:28 AM UTC-5, Karim Gillani wrote:
>>
>> Thanks. I don't believe this is a Red Hat issue as much as a
>> configuration issue. This is because I can replicate the issue using PSQL
>> and using the connect_timeout argument in PSQL, I can fix i
On Wed, Feb 26, 2020, at 12:11 AM, Karim Gillani wrote:
>
> We are using openshift which uses HAProxy. What I am looking for is why
> the connect_timeout may not being applied so that we can retry the call
> after re-connect to the other database pod.
>
> It is taking *up to two mi
the connect_timeout but I
don't see them.
Thanks
On Tuesday, 25 February 2020 21:11:56 UTC-8, Karim Gillani wrote:
>
> We are using openshift which uses HAProxy. What I am looking for is why
> the connect_timeout may not being applied so that we can retry the call
> after re-connect to the ot
it is moving a VIP
> from one machine to another. You'd want to be using a proxy server such as
> HAProxy or PGBouncer rather than relying upon changing network routing.
>
>
>
> On Tue, Feb 25, 2020, at 12:07 PM, Karim Gillani wrote:
>
> Please note I am using a Pool. And som
uot;patroni-mastertheq" (172.50.46.180) and accepting> TCP/IP connections on
port 5432?>>(Background on this error at: http://sqlalche.me/e/e3q8 )
Thanks
Karim
On Tuesday, 25 February 2020 08:49:19 UTC-8, Karim Gillani wrote:
>
> I am having an issue where whe
