Re: [HACKERS] psql casts aspersions on server reliability - Mailing list pgsql-hackers

From Laurenz Albe
Subject Re: [HACKERS] psql casts aspersions on server reliability
Date
Msg-id 1e9012b85ffaf04efb13859465804ce9b08ce073.camel@cybertec.at
Whole thread Raw
In response to Re: [HACKERS] psql casts aspersions on server reliability  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [HACKERS] psql casts aspersions on server reliability
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: PATCH: Add REINDEX tag to event triggers
Next
From: Michael Paquier
Date:
Subject: Re: GUC names in messages