Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qOylf-009csA-Op for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Jul 2023 11:02:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qOyld-009euX-Kz for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Jul 2023 11:02:49 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qOyld-009euP-Ba for pgsql-hackers@lists.postgresql.org; Thu, 27 Jul 2023 11:02:49 +0000 Received: from mail.db.is.i.nagoya-u.ac.jp ([133.6.203.151]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qOyla-000gDv-3C for pgsql-hackers@lists.postgresql.org; Thu, 27 Jul 2023 11:02:48 +0000 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (Authenticated sender: kuwamura) by mail.db.is.i.nagoya-u.ac.jp (Postfix) with ESMTPSA id 70D13C00DA for ; Thu, 27 Jul 2023 20:02:36 +0900 (JST) Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-3fbc0609cd6so8474175e9.1 for ; Thu, 27 Jul 2023 04:02:36 -0700 (PDT) X-Gm-Message-State: ABy/qLZSBnEvN8g51a715jD8Hg+wTgClHUNn3kvurqzmvMOJIucWzdLd SfU3Ax0ec33pIoLZqQiCErUVXUosrHKaHwCWAAA= X-Google-Smtp-Source: APBJJlFTxyXu+OJp6EctfjdfUI2qMEVcDEzFJRIy0c6d2WiFmZA7lu9ZuGIfRpcG6bV+Clrl3ArZwR7OzfnaO4F2y3o= X-Received: by 2002:a1c:7403:0:b0:3fb:403d:90c0 with SMTP id p3-20020a1c7403000000b003fb403d90c0mr1348167wmc.39.1690455754443; Thu, 27 Jul 2023 04:02:34 -0700 (PDT) MIME-Version: 1.0 References: <67cad2e7-f9c1-5eb0-a0be-99fd78571906@oss.nttdata.com> <20230417.173812.452521384661813597.horikyota.ntt@gmail.com> <53f03117-087f-5583-2c97-e82a3e9dc43e@oss.nttdata.com> In-Reply-To: <53f03117-087f-5583-2c97-e82a3e9dc43e@oss.nttdata.com> From: Kuwamura Masaki Date: Thu, 27 Jul 2023 20:01:56 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Issue in postgres_fdw causing unnecessary wait for cancel request reply To: Fujii Masao Cc: Jelte Fennema , Kyotaro Horiguchi , etsuro.fujita@gmail.com, pgsql-hackers@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000c091d2060175e69e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c091d2060175e69e Content-Type: text/plain; charset="UTF-8" Hi, Fujii-san > Regarding the WARNING message, another idea is to pass the return value > of PQgetCancel() directly to PQcancel() as follows. If NULL is passed, > PQcancel() will detect it and set the proper error message to errbuf. > Then the warning message "WARNING: could not send cancel request: > PQcancel() -- no cancel object supplied" is output. I agree to go with this. With this approach, the information behind the error (e.g., "out of memory") will disappear, I guess. I think we have to deal with it eventually. (I'm sorry, I don't have a good idea right now) However, the original issue is unnecessary waiting, and this should be fixed soon. So it is better to fix the problem this way and discuss retaining information in another patch IMO. I'm afraid I'm new to reviewing. If I'm misunderstanding something, please let me know. Masaki Kuwamura --000000000000c091d2060175e69e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Fujii-san

> Regarding the WARNING messa= ge, another idea is to pass the return value
> of PQgetCancel() direc= tly to PQcancel() as follows. If NULL is passed,
> PQcancel() will de= tect it and set the proper error message to errbuf.
> Then the warnin= g message "WARNING: =C2=A0could not send cancel request:
> PQcan= cel() -- no cancel object supplied" is output.

I agree to go wi= th this.

With this approach, the information behind the error (e.g.= , "out of memory") will disappear, I guess.
I think we have to= deal with it eventually. (I'm sorry, I don't have a good idea righ= t now)
However, the original issue is unnecessary waiting, and this shou= ld be fixed soon.
So it is better to fix the problem this way and discus= s retaining information in another patch IMO.

I'm afraid I'm= new to reviewing.
If I'm misunderstanding something, please let me = know.

Masaki Kuwamura
--000000000000c091d2060175e69e--