| 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 |
| 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 |