Horton

Re: BUG #17421: Core dump in ECPGdo() when calling PostgreSQL API from 32-bit client for RHEL8

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
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>
Date: 2022-06-06T15:01:52Z
Lists: pgsql-bugs

Attachments

"hirose.masay-01@fujitsu.com" <hirose.masay-01@fujitsu.com> writes:
> [Problem]
> The potential problem is no value is set to "message" after PQresultErrorField() 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 == NULL)
> |			message = 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

Commits

  1. Don't fail on libpq-generated error reports in ecpg_raise_backend().