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

From Bruce Momjian
Subject Re: [HACKERS] psql casts aspersions on server reliability
Date
Msg-id ZWC_AfdviG6pwPv1@momjian.us
Whole thread Raw
In response to Re: [HACKERS] psql casts aspersions on server reliability  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: [HACKERS] psql casts aspersions on server reliability
List pgsql-hackers
On Fri, Nov 24, 2023 at 04:06:22AM +0100, Laurenz Albe wrote:
> 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.

Yes, this is just a debug build so we can see the values of 'res'. 
Sorry for the confusion.  This attached patch has the elog() added so
you can reproduce what I saw.

I am actually unclear which exits should be labled as "abnormal".

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.

Attachment

pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: Table AM Interface Enhancements
Next
From: vignesh C
Date:
Subject: Re: pg_upgrade and logical replication