Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jIqVr-00050B-HU for psycopg@arkaria.postgresql.org; Mon, 30 Mar 2020 09:15:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jIqVq-0001PB-5X for psycopg@arkaria.postgresql.org; Mon, 30 Mar 2020 09:15:18 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jIqVp-0001Nf-O8 for psycopg@lists.postgresql.org; Mon, 30 Mar 2020 09:15:17 +0000 Received: from mail-oi1-x236.google.com ([2607:f8b0:4864:20::236]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jIqVj-0003Za-7K for psycopg@postgresql.org; Mon, 30 Mar 2020 09:15:16 +0000 Received: by mail-oi1-x236.google.com with SMTP id k18so15083019oib.3 for ; Mon, 30 Mar 2020 02:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VSC4NhRrhmYrPQ2Dd9h41Zo6NGxGegSJH4WidMsmYLg=; b=NY7E+Rkrni6Cs8FfQXQe5hgvqZNUePcAtrF5sGC0FupSGZW1W7nyQlQtha5Qtiu6mH MjbSUZ+T4lm09Rwkbvq1K+YiCXA7ndSm1+EQjlXJicsoe1Ki9m089JglZrnletTYa3oq obP3DATAJzKSeKQ5HKzZs/f1yG3kn6cT59IxfBeKdf3Pieo1RWIkjxHfJ+Wo3/Ayalte C3PoCrewPQANlwbaUDs7h2Qigfht+M5tIGQgQYP00fCC9VMRrtpoU2m33dRhevW6yEM0 KFNE3WLM9j4+Ycery0JH+0xnqliy1ulJJvHFSk5z8a8XVlYvPgxmvMsJaIj11OHYtZZN Qb8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VSC4NhRrhmYrPQ2Dd9h41Zo6NGxGegSJH4WidMsmYLg=; b=AN3IRAH8NXKacD4z//+fbDgTVKZxHpG3aWGheYP21nZCDkFoksrtRqfrBZPqBN5Oex WONwJmUiN6lgcQW4eiZZIhMuJxhKa3lfDl6mdVC9I+PdN9fByDr9wf+1cLgIoTGxpMwd 69CBnA2Q1JS8yLijY5YYQsnXPjzIBrpmu9BAhHXThpZSSKwG9krAciYF6USW+ucFfYrK dB3v6jSoG26QbAgzT5QvvRj0SSoxxvoA0vbnAIj4Z3QyC/4MtBIit1bqy1rOEf3r1w37 pk8knmDzNVhgycjQhTVWtK2h3L1b9eUo3LgFB+fvn3d2TjF0zyPw5NEVj3fh8GtaLdy+ hhkA== X-Gm-Message-State: ANhLgQ3SyxT0drbJ2eaPBNMXp1g/x80GhpSzBfDyPScRm1jUAdR8ujsr bBh+oX0Ru6YT5UVlqb85eArhx0bEF56Fz2hqKzM= X-Google-Smtp-Source: ADFU+vuBhdJiwJI8JVxvko8CIUEVhRVkoi/VIdTKloB1fi7A+WZgpzwIZuojxTf4SlzJSsBtDOMRQN+heRogFIeTenE= X-Received: by 2002:aca:4d86:: with SMTP id a128mr7023460oib.96.1585559710433; Mon, 30 Mar 2020 02:15:10 -0700 (PDT) MIME-Version: 1.0 References: <20200330074917.GA28993@campbell-lange.net> In-Reply-To: <20200330074917.GA28993@campbell-lange.net> From: Stefan Knecht Date: Mon, 30 Mar 2020 16:14:59 +0700 Message-ID: Subject: Re: psycopg3: a first report To: Rory Campbell-Lange Cc: Daniele Varrazzo , psycopg@postgresql.org Content-Type: multipart/alternative; boundary="0000000000004f84a505a20ee3dc" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --0000000000004f84a505a20ee3dc Content-Type: text/plain; charset="UTF-8" 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 wrote: > On 30/03/20, Stefan Knecht (knecht.stefan@gmail.com) 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/ --0000000000004f84a505a20ee3dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Rory, this is about established connections, not new = connections - psycopg2 already offers a connection timeout, but that is a d= ifferent thing. I don't want to drift too far off topic - but we are already using pgbo= uncer, and the problem isn't detected by it, either. I'm not a deve= loper but I believe the problem is the generic nature of some blocking sock= et calls, which may hang under some odd circumstances, and they remain hang= ing 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 m= onitoring 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 <rory@cam= pbell-lange.net> wrote:
On 30/03/20, Stefan Knecht (knecht.stefan@gmail.com) wrote:
> If I may, one thing that has been a constant troublemaker for us - run= ning
> 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/con= fig.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= =C2=A0zztat.net=C2=A0| @zztat_oracle | fb.me/zztat | zztat.net/blog/
--0000000000004f84a505a20ee3dc--