From: Tom Lane <tgl@sss.pgh.pa.us>
To: "hirose.masay-01@fujitsu.com" <hirose.masay-01@fujitsu.com>
cc: "'Michael Paquier'" <michael@paquier.xyz>,
        "'pgsql-bugs@lists.postgresql.org'" <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #17421: Core dump in ECPGdo() when calling PostgreSQL API
 from 32-bit client for RHEL8
In-reply-to: 
 <TYYPR01MB68109C3C722F18E2D070F350B8A29@TYYPR01MB6810.jpnprd01.prod.outlook.com>
References: <17421-790ff887e3188874@postgresql.org>
 <YhtsqXFtjC86HdeM@paquier.xyz> <2360630.1645979458@sss.pgh.pa.us>
 <TYYPR01MB68107FD3A60E960453525BF7B8069@TYYPR01MB6810.jpnprd01.prod.outlook.com>
 <YiM7gxu7cxarLUc4@paquier.xyz> <4070596.1646493542@sss.pgh.pa.us>
 <OSZPR01MB68168671C4115AF080C69610B8E79@OSZPR01MB6816.jpnprd01.prod.outlook.com>
 <TYYPR01MB68109C3C722F18E2D070F350B8A29@TYYPR01MB6810.jpnprd01.prod.outlook.com>
Comments: In-reply-to "hirose.masay-01@fujitsu.com"
 <hirose.masay-01@fujitsu.com>
	message dated "Mon, 06 Jun 2022 09:50:16 -0000"
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <901650.1654527620.0@sss.pgh.pa.us>
Date: Mon, 06 Jun 2022 11:01:52 -0400
Message-ID: <908758.1654527712@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/908758.1654527712%40sss.pgh.pa.us>
Precedence: bulk

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <901650.1654527620.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable

"hirose.masay-01@fujitsu.com" <hirose.masay-01@fujitsu.com> writes:
> [Problem]
> The potential problem is no value is set to "message" after PQresultErro=
rField() is called in ecpg_raise_backend().

Ah-hah.  You're right, and this explains the symptoms exactly, because
libpq-generated error results don't contain broken-down fields, so we'd
get a null precisely in cases such as lost connection.

> |		if (message =3D=3D NULL)
> |			message =3D ecpg_gettext("empty message text");

No, that'd be pretty unhelpful.  The best response is to substitute
PQerrorMessage(conn) in such cases.  We do that in, for example,
postgres_fdw.

(I don't feel a need to change ECPGnoticeReceiver, because that only
deals with NOTICE results which should always have such a field, and
PQerrorMessage wouldn't be relevant to a non-ERROR result anyway.)

Will fix, thanks for the report!

			regards, tom lane


------- =_aaaaaaaaaa0
Content-Type: text/x-diff;
	name="ecpg-cope-with-missing-primary-error-field.patch";
	charset="us-ascii"
Content-ID: <901650.1654527620.2@sss.pgh.pa.us>
Content-Description: ecpg-cope-with-missing-primary-error-field.patch
Content-Transfer-Encoding: quoted-printable

diff --git a/src/interfaces/ecpg/ecpglib/error.c b/src/interfaces/ecpg/ecp=
glib/error.c
index cd6c6a6819..26fdcdb69e 100644
--- a/src/interfaces/ecpg/ecpglib/error.c
+++ b/src/interfaces/ecpg/ecpglib/error.c
@@ -229,18 +229,17 @@ ecpg_raise_backend(int line, PGresult *result, PGcon=
n *conn, int compat)
 		return;
 	}
 =

-	if (result)
-	{
-		sqlstate =3D PQresultErrorField(result, PG_DIAG_SQLSTATE);
-		if (sqlstate =3D=3D NULL)
-			sqlstate =3D ECPG_SQLSTATE_ECPG_INTERNAL_ERROR;
-		message =3D PQresultErrorField(result, PG_DIAG_MESSAGE_PRIMARY);
-	}
-	else
-	{
+	/*
+	 * PQresultErrorField will return NULL if "result" is NULL, or if there =
is
+	 * no such field, which will happen for libpq-generated errors.  Fall ba=
ck
+	 * to PQerrorMessage in such cases.
+	 */
+	sqlstate =3D PQresultErrorField(result, PG_DIAG_SQLSTATE);
+	if (sqlstate =3D=3D NULL)
 		sqlstate =3D ECPG_SQLSTATE_ECPG_INTERNAL_ERROR;
+	message =3D PQresultErrorField(result, PG_DIAG_MESSAGE_PRIMARY);
+	if (message =3D=3D NULL)
 		message =3D PQerrorMessage(conn);
-	}
 =

 	if (strcmp(sqlstate, ECPG_SQLSTATE_ECPG_INTERNAL_ERROR) =3D=3D 0)
 	{

------- =_aaaaaaaaaa0--