On Thu, 2023-11-23 at 11:12 -0500, Bruce Momjian wrote: > On Wed, Nov 22, 2023 at 10:25:14PM -0500, Bruce Momjian wrote: > > Yes, you are correct. Here is a patch that implements the FATAL test, > > though I am not sure I have the logic correct or backwards, and I don't > > know how to test this. Thanks. > > I developed the attached patch which seems to work better. In testing > kill -3 on a backend or calling elog(FATAL) in the server for a > session, libpq's 'res' is NULL, meaning we don't have any status to > check for PGRES_FATAL_ERROR. It is very possible that libpq just isn't > stuctured to have the PGRES_FATAL_ERROR at the point where we issue this > message, and this is not worth improving. > > test=> select pg_sleep(100); > --> FATAL: FATAL called > > server closed the connection unexpectedly > --> This probably means the server terminated null > before or while processing the request. > The connection to the server was lost. Attempting reset: Succeeded.
I don't thing "terminated null" is a meaningful message. > libpq_append_conn_error(conn, "server closed the connection > unexpectedly\n" > - "\tThis probably means > the server terminated abnormally\n" > - "\tbefore or while > processing the request."); > + "\tThis probably means > the server terminated%s\n" > + "\tbefore or while > processing the request.", > + (conn->result == NULL) > ? " null" : > + > (conn->result->resultStatus == PGRES_FATAL_ERROR) ? > + "" : " abnormally"); Apart from the weird "null", will that work well for translation? > --- a/src/interfaces/libpq/fe-protocol3.c > +++ b/src/interfaces/libpq/fe-protocol3.c > @@ -2158,6 +2158,7 @@ pqFunctionCall3(PGconn *conn, Oid fnid, > if (pqGetErrorNotice3(conn, true)) > continue; > status = PGRES_FATAL_ERROR; > + fprintf(stderr, "Got 'E'\n"); > break; > case 'A': /* notify message */ > /* handle notify and go back to processing > return values */ That looks like a leftover debugging message. Yours, Laurenz Albe
