public inbox for [email protected]
help / color / mirror / Atom feedpsycopg3: a first report
8+ messages / 3 participants
[nested] [flat]
* psycopg3: a first report
@ 2020-03-27 10:46 Daniele Varrazzo <[email protected]>
2020-03-30 04:27 ` Re: psycopg3: a first report Stefan Knecht <[email protected]>
0 siblings, 1 reply; 8+ messages in thread
From: Daniele Varrazzo @ 2020-03-27 10:46 UTC (permalink / raw)
To: psycopg
Hello,
I have started working on psycopg3. Database communication is up and
running, sync and asyncio, and now I'm busy with the definition of the
adaptation layer.
You can read more at
https://www.varrazzo.com/blog/2020/03/26/psycopg3-first-report/
Comments are welcome. Cheers!
-- Daniele
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: psycopg3: a first report
2020-03-27 10:46 psycopg3: a first report Daniele Varrazzo <[email protected]>
@ 2020-03-30 04:27 ` Stefan Knecht <[email protected]>
2020-03-30 07:49 ` Re: psycopg3: a first report Rory Campbell-Lange <[email protected]>
2020-03-30 09:17 ` Re: psycopg3: a first report Daniele Varrazzo <[email protected]>
2020-03-30 10:53 ` Re: psycopg3: a first report Daniele Varrazzo <[email protected]>
0 siblings, 3 replies; 8+ messages in thread
From: Stefan Knecht @ 2020-03-30 04:27 UTC (permalink / raw)
To: Daniele Varrazzo <[email protected]>; +Cc: psycopg
Ciao Daniele
Glad to see progress being made! Well written blog!
If I may, one thing that has been a constant troublemaker for us - running
primarily on AWS - is timeouts. I would love to see a fundamental
implementation of timeouts at the connection level, regardless of activity
- e.g. in the middle of a query, between queries, etc.. If the connection
hangs (because the server disappeared or failed over) or does not respond
(particularly in the weird cases like when the destination IP just vanishes
and the tcp timeout kicks in) - I'd like to know about it within a
reasonable time and be able to react to that.
Stefan
On Fri, Mar 27, 2020 at 5:46 PM Daniele Varrazzo <[email protected]>
wrote:
> Hello,
>
> I have started working on psycopg3. Database communication is up and
> running, sync and asyncio, and now I'm busy with the definition of the
> adaptation layer.
>
> You can read more at
> https://www.varrazzo.com/blog/2020/03/26/psycopg3-first-report/
>
> Comments are welcome. Cheers!
>
> -- Daniele
>
>
>
--
//
zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!
Visit us at zztat.net | @zztat_oracle | fb.me/zztat | zztat.net/blog/
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: psycopg3: a first report
2020-03-27 10:46 psycopg3: a first report Daniele Varrazzo <[email protected]>
2020-03-30 04:27 ` Re: psycopg3: a first report Stefan Knecht <[email protected]>
@ 2020-03-30 07:49 ` Rory Campbell-Lange <[email protected]>
2020-03-30 09:14 ` Re: psycopg3: a first report Stefan Knecht <[email protected]>
2 siblings, 1 reply; 8+ messages in thread
From: Rory Campbell-Lange @ 2020-03-30 07:49 UTC (permalink / raw)
To: Stefan Knecht <[email protected]>; +Cc: Daniele Varrazzo <[email protected]>; psycopg
On 30/03/20, Stefan Knecht ([email protected]) wrote:
> If I may, one thing that has been a constant troublemaker for us - running
> primarily on AWS - is timeouts.
If the issue is disappearing hosts or general connectivity problems,
isn't that problem best dealt with by pg_bouncer?
https://www.pgbouncer.org/config.html#connection-sanity-checks-timeouts
Specifically you may wish to refer to server_connect_timeout.
Rory
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: psycopg3: a first report
2020-03-27 10:46 psycopg3: a first report Daniele Varrazzo <[email protected]>
2020-03-30 04:27 ` Re: psycopg3: a first report Stefan Knecht <[email protected]>
2020-03-30 07:49 ` Re: psycopg3: a first report Rory Campbell-Lange <[email protected]>
@ 2020-03-30 09:14 ` Stefan Knecht <[email protected]>
2020-03-30 09:30 ` Re: psycopg3: a first report Daniele Varrazzo <[email protected]>
2020-03-30 10:00 ` Re: psycopg3: a first report Rory Campbell-Lange <[email protected]>
0 siblings, 2 replies; 8+ messages in thread
From: Stefan Knecht @ 2020-03-30 09:14 UTC (permalink / raw)
To: Rory Campbell-Lange <[email protected]>; +Cc: Daniele Varrazzo <[email protected]>; psycopg
Rory, this is about established connections, not new connections - psycopg2
already offers a connection timeout, but that is a different thing. I don't
want to drift too far off topic - but we are already using pgbouncer, and
the problem isn't detected by it, either. I'm not a developer but I believe
the problem is the generic nature of some blocking socket calls, which may
hang under some odd circumstances, and they remain hanging until some odd
ssl timeout is reached (15 minutes+ which is a very long time for any
application to be hanging in limbo, but more so for our own monitoring
tools which are written in Python).
Having the client provide general handling for in-flight timeouts would be
the overall best solution imho.
On Mon, Mar 30, 2020 at 2:48 PM Rory Campbell-Lange <[email protected]>
wrote:
> On 30/03/20, Stefan Knecht ([email protected]) wrote:
> > If I may, one thing that has been a constant troublemaker for us -
> running
> > primarily on AWS - is timeouts.
>
> If the issue is disappearing hosts or general connectivity problems,
> isn't that problem best dealt with by pg_bouncer?
>
> https://www.pgbouncer.org/config.html#connection-sanity-checks-timeouts
>
> Specifically you may wish to refer to server_connect_timeout.
>
> Rory
>
>
--
//
zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!
Visit us at zztat.net | @zztat_oracle | fb.me/zztat | zztat.net/blog/
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: psycopg3: a first report
2020-03-27 10:46 psycopg3: a first report Daniele Varrazzo <[email protected]>
2020-03-30 04:27 ` Re: psycopg3: a first report Stefan Knecht <[email protected]>
2020-03-30 07:49 ` Re: psycopg3: a first report Rory Campbell-Lange <[email protected]>
2020-03-30 09:14 ` Re: psycopg3: a first report Stefan Knecht <[email protected]>
@ 2020-03-30 09:30 ` Daniele Varrazzo <[email protected]>
1 sibling, 0 replies; 8+ messages in thread
From: Daniele Varrazzo @ 2020-03-30 09:30 UTC (permalink / raw)
To: Stefan Knecht <[email protected]>; +Cc: Rory Campbell-Lange <[email protected]>; psycopg
>
> Having the client provide general handling for in-flight timeouts would be
> the overall best solution imho.
>
I agree on this: the client should be aware of timeouts, both on connection
and querying.
If we keep the waiting loops in Python and only use non-blocking C
functions I think making sure every operation has a timeout is achievable.
-- Daniele
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: psycopg3: a first report
2020-03-27 10:46 psycopg3: a first report Daniele Varrazzo <[email protected]>
2020-03-30 04:27 ` Re: psycopg3: a first report Stefan Knecht <[email protected]>
2020-03-30 07:49 ` Re: psycopg3: a first report Rory Campbell-Lange <[email protected]>
2020-03-30 09:14 ` Re: psycopg3: a first report Stefan Knecht <[email protected]>
@ 2020-03-30 10:00 ` Rory Campbell-Lange <[email protected]>
1 sibling, 0 replies; 8+ messages in thread
From: Rory Campbell-Lange @ 2020-03-30 10:00 UTC (permalink / raw)
To: Stefan Knecht <[email protected]>; +Cc: Daniele Varrazzo <[email protected]>; psycopg
On 30/03/20, Stefan Knecht ([email protected]) wrote:
> Rory, this is about established connections, not new connections - psycopg2
> already offers a connection timeout, but that is a different thing. I don't
> want to drift too far off topic - but we are already using pgbouncer, and
> the problem isn't detected by it, either. I'm not a developer but I believe
> the problem is the generic nature of some blocking socket calls, which may
> hang under some odd circumstances, and they remain hanging until some odd
> ssl timeout is reached (15 minutes+ which is a very long time for any
> application to be hanging in limbo, but more so for our own monitoring
> tools which are written in Python).
My apologies for the misunderstanding.
This sounds like the hanging tcp/ip problem one can get with
disappearing web server clients. We've had that problem with mobiles
dropping out presumably because they go out of range, and the provider
not dropping the connection because they might come back.
We deal with this in apache by having a fairly aggressive
KeepAliveTimeout parameter.
Having this problem in one's own stack sounds scary.
I'm very intrigued by Daniele's suggestion that having a per-operation
timeout on the client is achievable.
Rory
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: psycopg3: a first report
2020-03-27 10:46 psycopg3: a first report Daniele Varrazzo <[email protected]>
2020-03-30 04:27 ` Re: psycopg3: a first report Stefan Knecht <[email protected]>
@ 2020-03-30 09:17 ` Daniele Varrazzo <[email protected]>
2 siblings, 0 replies; 8+ messages in thread
From: Daniele Varrazzo @ 2020-03-30 09:17 UTC (permalink / raw)
To: Stefan Knecht <[email protected]>; +Cc: psycopg
Hi Stefan,
On Mon, 30 Mar 2020, 17:27 Stefan Knecht, <[email protected]> wrote:
>
If I may, one thing that has been a constant troublemaker for us - running
> primarily on AWS - is timeouts. I would love to see a fundamental
> implementation of timeouts at the connection level, regardless of activity
> - e.g. in the middle of a query, between queries, etc.. If the connection
> hangs (because the server disappeared or failed over) or does not respond
> (particularly in the weird cases like when the destination IP just vanishes
> and the tcp timeout kicks in) - I'd like to know about it within a
> reasonable time and be able to react to that.
>
It would be interesting to set up integration tests wirh connections being
disrupted in various ways and at different moments during connection and
query processes. I'd rather do them in a test framework rather than one-off.
Mitmproxy could be a nice tool to build them.
https://mitmproxy.org/
-- Daniele
>
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: psycopg3: a first report
2020-03-27 10:46 psycopg3: a first report Daniele Varrazzo <[email protected]>
2020-03-30 04:27 ` Re: psycopg3: a first report Stefan Knecht <[email protected]>
@ 2020-03-30 10:53 ` Daniele Varrazzo <[email protected]>
2 siblings, 0 replies; 8+ messages in thread
From: Daniele Varrazzo @ 2020-03-30 10:53 UTC (permalink / raw)
To: Stefan Knecht <[email protected]>; +Cc: psycopg
On Mon, 30 Mar 2020 at 17:27, Stefan Knecht <[email protected]> wrote:
> I would love to see a fundamental implementation of timeouts at the connection level, regardless of activity
By the way, did you try playing with the libpq socket options, such as
tcp_user_timeout?
-- Daniele
^ permalink raw reply [nested|flat] 8+ messages in thread
end of thread, other threads:[~2020-03-30 10:53 UTC | newest]
Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-03-27 10:46 psycopg3: a first report Daniele Varrazzo <[email protected]>
2020-03-30 04:27 ` Stefan Knecht <[email protected]>
2020-03-30 07:49 ` Rory Campbell-Lange <[email protected]>
2020-03-30 09:14 ` Stefan Knecht <[email protected]>
2020-03-30 09:30 ` Daniele Varrazzo <[email protected]>
2020-03-30 10:00 ` Rory Campbell-Lange <[email protected]>
2020-03-30 09:17 ` Daniele Varrazzo <[email protected]>
2020-03-30 10:53 ` Daniele Varrazzo <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox