Re: libpq maligning postgres stability

From: "Jelte Fennema-Nio" <postgres(at)jeltef(dot)nl>
To: "Andres Freund" <andres(at)anarazel(dot)de>
Cc: <pgsql-hackers(at)postgresql(dot)org>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>
Subject: Re: libpq maligning postgres stability
Date: 2026-05-26 07:22:07
Message-ID: DISFEF23Y30A.3H6YMBMPYVF8I@jeltef.nl
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 27 Mar 2025 at 16:19, Andres Freund <andres(at)anarazel(dot)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 Content-Type Size
v1-0001-libpq-Consider-a-connection-with-a-FATAL-error-to.patch text/x-patch 2.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2026-05-26 07:32:39 Re: Fix bug of CHECK constraint enforceability recursion
Previous Message Chao Li 2026-05-26 07:14:25 Re: Avoid leaking system path from pg_available_extensions