Re: error handling in pqRowProcessor broken - Mailing list pgsql-hackers

From Tom Lane
Subject Re: error handling in pqRowProcessor broken
Date
Msg-id 2617038.1650395765@sss.pgh.pa.us
Whole thread Raw
In response to error handling in pqRowProcessor broken  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: error handling in pqRowProcessor broken
List pgsql-hackers
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> I find that this doesn't work anymore.  If you set *errmsgp = "some
> message" and return 0, then psql will just print a result set with zero
> rows.

Ah, I see the problem: a few places in fe-protocol3 didn't get the memo
that conn->error_result represents a "pending" PGresult that hasn't
been constructed yet.  The attached fixes it for me --- can you try it
on whatever test case led you to this?

> (Even before the above commit, the handling of the returned message was
> a bit weird: The error output was just the message string, without any
> prefix like "ERROR:".)

libpq's always acted that way for internally-generated messages.
Most of them are so rare that we're probably not used to seeing 'em.
Perhaps there's a case for making it more verbose, but right now
doesn't seem like the time to undertake that.

            regards, tom lane

diff --git a/src/interfaces/libpq/fe-exec.c b/src/interfaces/libpq/fe-exec.c
index 78cff4475c..1b9c04f47e 100644
--- a/src/interfaces/libpq/fe-exec.c
+++ b/src/interfaces/libpq/fe-exec.c
@@ -1196,6 +1196,7 @@ pqSaveParameterStatus(PGconn *conn, const char *name, const char *value)
  *      Returns 1 if OK, 0 if error occurred.
  *
  * On error, *errmsgp can be set to an error string to be returned.
+ * (Such a string should already be translated via libpq_gettext().)
  * If it is left NULL, the error is presumed to be "out of memory".
  *
  * In single-row mode, we create a new result holding just the current row,
diff --git a/src/interfaces/libpq/fe-protocol3.c b/src/interfaces/libpq/fe-protocol3.c
index 94b4a448b9..e0da22dba7 100644
--- a/src/interfaces/libpq/fe-protocol3.c
+++ b/src/interfaces/libpq/fe-protocol3.c
@@ -209,7 +209,7 @@ pqParseInput3(PGconn *conn)
                 case 'C':        /* command complete */
                     if (pqGets(&conn->workBuffer, conn))
                         return;
-                    if (conn->result == NULL)
+                    if (conn->result == NULL && !conn->error_result)
                     {
                         conn->result = PQmakeEmptyPGresult(conn,
                                                            PGRES_COMMAND_OK);
@@ -263,7 +263,7 @@ pqParseInput3(PGconn *conn)
                     }
                     break;
                 case 'I':        /* empty query */
-                    if (conn->result == NULL)
+                    if (conn->result == NULL && !conn->error_result)
                     {
                         conn->result = PQmakeEmptyPGresult(conn,
                                                            PGRES_EMPTY_QUERY);
@@ -281,7 +281,7 @@ pqParseInput3(PGconn *conn)
                     if (conn->cmd_queue_head &&
                         conn->cmd_queue_head->queryclass == PGQUERY_PREPARE)
                     {
-                        if (conn->result == NULL)
+                        if (conn->result == NULL && !conn->error_result)
                         {
                             conn->result = PQmakeEmptyPGresult(conn,
                                                                PGRES_COMMAND_OK);
@@ -362,7 +362,7 @@ pqParseInput3(PGconn *conn)
                     if (conn->cmd_queue_head &&
                         conn->cmd_queue_head->queryclass == PGQUERY_DESCRIBE)
                     {
-                        if (conn->result == NULL)
+                        if (conn->result == NULL && !conn->error_result)
                         {
                             conn->result = PQmakeEmptyPGresult(conn,
                                                                PGRES_COMMAND_OK);

pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Readd use of TAP subtests
Next
From: David Zhang
Date:
Subject: Re: postgres_fdw: commit remote (sub)transactions in parallel during pre-commit