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

From Jelte Fennema-Nio
Subject Re: libpq maligning postgres stability
Date
Msg-id DISFEF23Y30A.3H6YMBMPYVF8I@jeltef.nl
Whole thread
In response to libpq maligning postgres stability  (Andres Freund <andres@anarazel.de>)
Responses Re: libpq maligning postgres stability
List pgsql-hackers
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)

Attachment

pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Re: Avoid leaking system path from pg_available_extensions
Next
From: Álvaro Herrera
Date:
Subject: Re: Fix bug of CHECK constraint enforceability recursion