public inbox for [email protected]  

help / color / mirror / Atom feed

From: Bruce Momjian <[email protected]>
To: Laurenz Albe <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: [HACKERS] psql casts aspersions on server reliability
Date: Thu, 7 Dec 2023 21:59:01 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CA+TgmoZYvqmyQpzSUdtDmtk4Aj94MppDGe9qVJczbPLy4G2Yfg@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On Fri, Nov 24, 2023 at 10:19:29AM -0500, Bruce Momjian wrote:
> 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
> > > structured 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 labeled as "abnormal".

There are five call sites which issue this message, so I looked at
adding "abnormally" just at the call sites where it made sense, but I
couldn't find a pattern.  I don't plan to pursue this further.

-- 
  Bruce Momjian  <[email protected]>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.

view thread (3+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: [HACKERS] psql casts aspersions on server reliability
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox