Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pmQjE-0001qZ-Md for pgsql-hackers@arkaria.postgresql.org; Wed, 12 Apr 2023 03:01:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pmQjD-00033Y-Dx for pgsql-hackers@arkaria.postgresql.org; Wed, 12 Apr 2023 03:00:59 +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 1pmQjD-00033O-4J for pgsql-hackers@lists.postgresql.org; Wed, 12 Apr 2023 03:00:59 +0000 Received: from mail-pj1-x102c.google.com ([2607:f8b0:4864:20::102c]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pmQjA-0002uN-Sr for pgsql-hackers@lists.postgresql.org; Wed, 12 Apr 2023 03:00:58 +0000 Received: by mail-pj1-x102c.google.com with SMTP id mn5-20020a17090b188500b00246eddf34f6so2423643pjb.0 for ; Tue, 11 Apr 2023 20:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681268456; x=1683860456; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:from:subject:cc:to:message-id:date:from:to:cc:subject :date:message-id:reply-to; bh=V6qcP+qcBMkoWzVXga+ySMKREdlrvdL73uPDG0mwH7E=; b=P+0XwxVHjkQgi5UhKXFutuvQAye+uDk4shGTgfwB9Xaaj1Qbl7wM83538JXS+Bkz3O 4blEX+nduBbbPC1576m4B/kxDG1RkpVo4MX55i9s+ZK6UiYmg/MHV8t586Uw4zKoGxtF EhwkKwM3G6XH815Kq4T2PotI1o7y3vblQV6ad5kCsmrVFds7ecjE4si98PA6Yp34UNMo sqFRd6vGKiBimAIB0DV1X4nZ7dK2GD4nyHJmkP8qeFCDdW611cJtKAqURYeEUYaJLwa9 bvwVZI45BV3H7QWzH0nnyo7QWQakWzk5Gmvp9DiSlH2iW3CYkRZHhYHNu2sEVFYrcTaY 0zCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681268456; x=1683860456; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:from:subject:cc:to:message-id:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=V6qcP+qcBMkoWzVXga+ySMKREdlrvdL73uPDG0mwH7E=; b=M7Is6hdBjVNFUrEOk0aM+BODoS+8wd6a2oK59N65DALrB4Mmf2noZYxFTv3KTOu4O+ ztKIjNLsoot/7kN8GLqcheqCo2yrCPjrWFis2/1FMn0LEFTPWwyrQdFTvjkJ5CZYP7e9 JrQl0QFkr2JrX4LgKYiZt1xJydMpoz/jHn/DHZm54bYCe7Wo2jwXxhKR7EEBqOJq+Xhv WwGL3/TmuYNcB8A7xpqrCPRgIR3+JvSK70uwonutsGdOqfbZUDIfJR+jwcU/hoWepa0+ h3bJrJoAJk9lFOcfhRjyQQLaz/kmJOBcnobuZiUHfc8YOejanj/lel4Zk5Pr325eTBWB 9t0A== X-Gm-Message-State: AAQBX9ff8khbMcylcFvzc8u1NUs3Q0eWuHQsJi9c/hq2cyST7L0fSFOw tll7b6Gw2Zl8njuHjmyRD+I= X-Google-Smtp-Source: AKy350bTOagT9rzn506ixeIF9Zpx6uO5WBDDVE+zoPEzZJuGtf1phk4B/mkB2eis4vtN/04jmg4ymQ== X-Received: by 2002:a05:6a20:ba94:b0:eb:b99b:916 with SMTP id fb20-20020a056a20ba9400b000ebb99b0916mr389651pzb.20.1681268455802; Tue, 11 Apr 2023 20:00:55 -0700 (PDT) Received: from localhost (KD036014041111.ppp-bb.dion.ne.jp. [36.14.41.111]) by smtp.gmail.com with ESMTPSA id b3-20020a655783000000b004fb5f4bf585sm9241391pgr.78.2023.04.11.20.00.54 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Tue, 11 Apr 2023 20:00:55 -0700 (PDT) Date: Wed, 12 Apr 2023 12:00:53 +0900 (JST) Message-Id: <20230412.120053.1851827772375524248.horikyota.ntt@gmail.com> To: masao.fujii@oss.nttdata.com Cc: pgsql-hackers@lists.postgresql.org Subject: Re: Issue in postgres_fdw causing unnecessary wait for cancel request reply From: Kyotaro Horiguchi In-Reply-To: References: User-Agent: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk At Wed, 12 Apr 2023 03:36:01 +0900, Fujii Masao wrote in > Attached patch fixes this issue. It ensures that postgres_fdw only > waits > for a reply if a cancel request is actually issued. Additionally, > it improves PQgetCancel() to set error messages in certain error > cases, > such as when out of memory occurs and malloc() fails. Moreover, > it enhances postgres_fdw to report a warning message when > PQgetCancel() > returns NULL, explaining the reason for the NULL value. > > Thought? I wondered why the connection didn't fail in the first place. After digging into it, I found (or remembered) that local (or AF_UNIX) connections ignore the timeout value at making a connection. I think the real issue here is that PGgetCancel is unnecessarily checking its value and failing as a result. Otherwise there would be no room for failure in the call to PQgetCancel() at that point in the example case. PQconnectPoll should remove the ignored parameters at connection or PQgetCancel should ingore the unreferenced (or unchecked) parameters. For example, the below diff takes the latter way and seems working (for at least AF_UNIX connections) diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c index 40fef0e2c8..30e2ab54ba 100644 --- a/src/interfaces/libpq/fe-connect.c +++ b/src/interfaces/libpq/fe-connect.c @@ -4718,6 +4718,10 @@ PQgetCancel(PGconn *conn) cancel->keepalives_idle = -1; cancel->keepalives_interval = -1; cancel->keepalives_count = -1; + + if (conn->connip == 0) + return cancel; + if (conn->pgtcp_user_timeout != NULL) { if (!parse_int_param(conn->pgtcp_user_timeout, Of course, it's not great that pgfdw_cancel_query_begin() ignores the result from PQgetCancel(), but I think we don't need another ereport. regards. -- Kyotaro Horiguchi NTT Open Source Software Center