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

From Andres Freund
Subject Re: libpq maligning postgres stability
Date
Msg-id ifw6jojzfvhr6rcmofmpnj5w5jdq4uy5dmfacrd2i4uq54wfyc@yrmcv6fzjmzi
Whole thread
In response to Re: libpq maligning postgres stability  ("Jelte Fennema-Nio" <postgres@jeltef.nl>)
Responses Re: libpq maligning postgres stability
List pgsql-hackers
Hi,

On 2026-05-26 09:22:07 +0200, Jelte Fennema-Nio wrote:
> On Thu, 27 Mar 2025 at 16:19, Andres Freund <andres@anarazel.de> wrote:
> > And we don't even just add this message when the connection was actually
> > closed unexpectedly, we often do it even when we *did* get a FATAL, as in this
> > example:
> > 
> > psql -c 'select pg_terminate_backend(pg_backend_pid())'
> > FATAL:  57P01: terminating connection due to administrator command
> > LOCATION:  ProcessInterrupts, postgres.c:3351
> > server closed the connection unexpectedly
> >         This probably means the server terminated abnormally
> >         before or while processing the request.
> > connection to server was lost
> > 
> > 
> > I think this one is mostly a weakness in how libpq tracks connection state,
> > but it kind of shows the silliness of claiming postgres probably crashed.
> 
> I ran into this for the nth time (this time while trying to have psql
> handle certain FATAL errors differently). Turns out fixing this is
> actually really simple. All that's needed is to mark a connection as
> CONNECTION_BAD whenever a FATAL or PANIC error is received by the
> client.
> 
> (this change is intended for PG20)

Note that the tests don't pass with this applied:

https://github.com/postgresql-cfbot/postgresql/actions/runs/27235961657

- Andres



pgsql-hackers by date:

Previous
From: Zsolt Parragi
Date:
Subject: Re: Support EXCEPT for TABLES IN SCHEMA publications
Next
From: Jeff Davis
Date:
Subject: Re: Avoid orphaned objects dependencies, take 3