Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gHVLl-0006BE-1k for psycopg@arkaria.postgresql.org; Tue, 30 Oct 2018 14:50:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gHVLi-0008DL-QB for psycopg@arkaria.postgresql.org; Tue, 30 Oct 2018 14:50:30 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gHVLi-0008Bw-Az for psycopg@lists.postgresql.org; Tue, 30 Oct 2018 14:50:30 +0000 Received: from mail-qt1-x844.google.com ([2607:f8b0:4864:20::844]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gHVLe-00025U-Rq for psycopg@postgresql.org; Tue, 30 Oct 2018 14:50:28 +0000 Received: by mail-qt1-x844.google.com with SMTP id q41-v6so13728215qtq.10 for ; Tue, 30 Oct 2018 07:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r9jJA1SUkSFCxj7/rMXXIzc9bsCgasT3XcYH5CdrvQE=; b=JAEJyMMhCZDZVO6nWoSMqgVEP1c3gTznOTQN9cq08Nbq2bSWEst+Epplcv8Cuf8Vn9 xoyBIHpovWKtKjJmL5ad8TfSC6gy1GJMcIWxNkKebX38xjx3L7pc6h1J9bC2fdItL/d3 ZB8UA7lp6aCNmlZtYelbjz18ZHfgBrwayUMM5f72Gd7d5L+ZknhDYvxMw9QcC8vc3j2x DgngXN/5uscCAn2ZYWhqIPpXQJQc+jvM+iSLgAW0SRo/QOSYaSCGKFs4EoA/FO9SLAdh +SJbkH+7vP4O3EN4IN3o2thQ9Y9CR/kkaCxkaPS0Cv1+5g9QoXLyMpq0D6JcpH6GOc2v kjTw== 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=r9jJA1SUkSFCxj7/rMXXIzc9bsCgasT3XcYH5CdrvQE=; b=c4761z57wMCnI7riT5bZf04+ylDuqvLKuS4fZUncYf/uC3Th32qgJXfJsqiIESe66I WB2uE6bTQuR/pDSbO+NKKY5tkObhidvaEKvkiaQCAKnmfM9AqVen1FIJsO1Lci6tM2Yj qW6jeLpSUSFdv35BQp7s2rq+SSOtQYzjD2Vbg53aIG2K00hIHUxkhJkQo9ReaKwROk/6 YNTWnE1SIatQF8SCUtr+MSrslS9UeVcODwWh+EXXy28gTjQBR2/CcCSYDhz95B+HFNxR Km0E+6oGazeNP77nIofiH7NxpCxAU72wgyUpSltEBqjwDJjibuUQs56G0guOkuTIiphg BWwA== X-Gm-Message-State: AGRZ1gIp84znB5XW/dr0IvfRYH66zhAoixapDwutOOYKdFcrbKtdeiQH g4sYEXtxTOPaa68u3Op17EjGJf8TUcl2ngrB3Yyd3w== X-Google-Smtp-Source: AJdET5d1BnNqFj8Y+lA+0W5e4RMVDGMmk2a3c6FmUO4YSN0YPhMFZ7ipR7zP6y6Go+j0n0KcGu7HR8MjrLiimvHOn+Q= X-Received: by 2002:a0c:8a29:: with SMTP id 38mr16725381qvt.222.1540911025604; Tue, 30 Oct 2018 07:50:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Akshay Joshi Date: Tue, 30 Oct 2018 20:20:14 +0530 Message-ID: Subject: Re: psycopg2 conn.poll() hangs when used with sshtunnel To: Daniele Varrazzo Cc: psycopg@postgresql.org Content-Type: multipart/alternative; boundary="0000000000004fe3b20579734ecd" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --0000000000004fe3b20579734ecd Content-Type: text/plain; charset="UTF-8" Thanks Daniele On Tue, 30 Oct 2018, 19:56 Daniele Varrazzo On Tue, Oct 30, 2018 at 1:55 PM Akshay Joshi < > akshay.joshi@enterprisedb.com> wrote: > >> Hi >> >> On Tue, 30 Oct 2018, 19:17 Daniele Varrazzo > wrote: >> >>> It seems to me that the problem is in pqpath.c pq_get_last_result() >>> function. The loop assumes PQgetResult won't block, which seems always the >>> case with the direct connection, but PQisBusy() actually returns 1 >>> connecting through the tunnel. >>> >>> So at a first read, the simplification given by pq_get_last_result() is >>> broken: the results should be returned one by one in the normal loop going >>> through PQisBusy(), PQconsumeInput(), and the polling machinery. It seems a >>> chunky refactoring but as it is now I don't like pq_get_last_result() >>> anymore :( >>> >> >> What changes should I made to fix this? Or it should be fixed in >> psycopg2 itself. >> > > It is a problem in psycopg. I have a quick fix I can release with the next > bugfix if it shows no regression ( > https://github.com/psycopg/psycopg2/issues/801). A better fix requires a > non trivial rewrite of the async and green paths ( > https://github.com/psycopg/psycopg2/issues/802): I'd like to do it but it > may happen later if the band aid holds. > > I was just about to prepare the 2.7.6 release, so if the quick fix is easy > and doesn't cause regressions it will be released soon. > > -- Daniele > > --0000000000004fe3b20579734ecd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Daniele=C2=A0

=
On Tue, 30 Oct 2018, 19:56 Daniele Varrazzo <daniele.varrazzo@gmail.com wrote:
On Tue, Oct 30, = 2018 at 1:55 PM Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:
Hi

It seems to me that the problem is in pqpath.c pq_get_l= ast_result() function. The loop assumes PQgetResult won't block, which = seems always the case with the direct connection, but PQisBusy() actually r= eturns 1 connecting through the tunnel.

So at a first re= ad, the simplification given by pq_get_last_result() is broken: the results= should be returned one by one in the normal loop going through PQisBusy(),= PQconsumeInput(), and the polling machinery. It seems a chunky refactoring= but as it is now I don't like pq_get_last_result() anymore :(

=C2=A0 =C2=A0 What changes should I made to fix this? Or it shoul= d be fixed in psycopg2 itself.

= It is a problem in psycopg. I have a quick fix I can release with the next = bugfix if it shows no regression (https://github.com/p= sycopg/psycopg2/issues/801). A better fix requires a non trivial rewrit= e of the async and green paths (https://github.com/psy= copg/psycopg2/issues/802): I'd like to do it but it may happen late= r if the band aid holds.

I was just about to prepa= re the 2.7.6 release, so if the quick fix is easy and doesn't cause reg= ressions it will be released soon.

-- Daniele

--0000000000004fe3b20579734ecd--