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 1mt48k-0002lA-R3 for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Dec 2021 08:41:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mt48j-0001ES-N1 for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Dec 2021 08:41:57 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mt48j-0001EJ-Dx for pgsql-hackers@lists.postgresql.org; Fri, 03 Dec 2021 08:41:57 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mt48c-0007MP-1r for pgsql-hackers@lists.postgresql.org; Fri, 03 Dec 2021 08:41:57 +0000 Received: from [192.168.11.7] (p2638163-ipngn12701funabasi.chiba.ocn.ne.jp [180.59.132.163]) by oss.nttdata.com (Postfix) with ESMTPSA id 8A42F607B9; Fri, 3 Dec 2021 17:41:44 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.4 at oss.nttdata.com Message-ID: Date: Fri, 3 Dec 2021 17:41:44 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: issue in pgfdw_report_error()? Content-Language: en-US To: Bharath Rupireddy Cc: PostgreSQL Hackers References: <477c16c8-7ea4-20fc-38d5-ed3a77ed616c@oss.nttdata.com> <41aae5d4-4d11-85f6-8f32-1bb5349ce959@oss.nttdata.com> <192a2107-7e37-64d6-c5b3-c45448ba2e9e@oss.nttdata.com> From: Fujii Masao In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021/11/22 13:59, Bharath Rupireddy wrote: > On Mon, Nov 22, 2021 at 8:17 AM Fujii Masao wrote: >>> Well, in that case, why can't we get rid of "(message_primary != NULL" >>> and just have "message_primary[0] != '\0' ? errmsg_internal("%s", >>> message_primary) : errmsg("could not obtain message string for remote >>> error")" ? >> >> That's possible if we can confirm that PQerrorMessage() never returns >> NULL all the cases. I'm not sure how much it's worth doing that, though.. >> It seems more robust to check also NULL there. > > Okay. > >>> BTW, we might have to fix it in dblink_res_error too? >> >> Yeah, that's good idea. I included that change in the patch. Attached. > > Thanks. pgfdw_report_error_v2 patch looks good to me. Pushed. Thanks! Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION