Re: libpq maligning postgres stability - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: libpq maligning postgres stability
Date
Msg-id Z_RTvenumUVGrdXY@momjian.us
Whole thread Raw
In response to Re: libpq maligning postgres stability  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Mar 27, 2025 at 11:48:26AM -0400, Robert Haas wrote:
> On Thu, Mar 27, 2025 at 11:19 AM Andres Freund <andres@anarazel.de> wrote:
> > We have several places in libpq where libpq says that a connection closing is
> > probably due to a server crash with a message like:
> >
> > server closed the connection unexpectedly
> >         This probably means the server terminated abnormally
> >         before or while processing
> >
> > I think this is rather unhelpful, at least these days. There are a lot of
> > reasons the connection could have failed, the server having terminated
> > abnormally is just one of them.
> >
> > It's common to see this due to network issues, for example.  I've quite a few
> > times fielded worried questions of postgres users due to the message.
> 
> Yeah, I agree. I used to think this hint was helpful, but it's gotten
> less helpful as the years have passed, because the server is more
> stable these days. Another thing that can cause this (as discussed in
> Discord) is that the individual backend process can have died, but not
> the server as a whole. In that case, the hint is only accurate if you
> mean "server" to read your individual server process.
> 
> I wonder if, in addition to removing the hint, we could also consider
> rewording the message. For example, a slight rewording to "server
> connection closed unexpectedly" would avoid implying that it was the
> server that took action, which is correct, because it could be a
> firewall in between the machines or even security software on the
> client side.  Maybe there is some more dramatic rewording that is even
> better, but there's probably some value in keeping it similar to what
> people are used to seeing.

FYI, I researched these messages in 2023 to see if the message can be
adjusted based on the code line generating the message, but with no
conclusion:

    https://www.postgresql.org/message-id/flat/CA%2BTgmoZYvqmyQpzSUdtDmtk4Aj94MppDGe9qVJczbPLy4G2Yfg%40mail.gmail.com

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

  Do not let urgent matters crowd out time for investment in the future.



pgsql-hackers by date:

Previous
From: James Hunter
Date:
Subject: Re: Proposal: "query_work_mem" GUC, to distribute working memory to the query's individual operators
Next
From: Masahiko Sawada
Date:
Subject: Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row