Re: [PATCH] immediately kill psql process if server is not running.

On 11/8/24 19:42, Srinath Reddy Sadipiralla wrote:
> Hi ,
>
> When a user tries to enter a large query, thinking the server is still
> running, and to their surprise, they discover that the server has
> crashed or stopped, I have observed that the psql process will still be
> running if it is idle even after the server crashes or stops.
>
> solved this using 2 methods:
>
> 1) using a thread (supports --with-readline and --without-readline)
>
> To address this surprise circumstance, I created a patch that creates a
> new thread within the psql process to monitor the File Descriptor of the
> psql process,this thread will monitor for -1 or 0 on psql’s FD using
> select() and recv()  functions .If either one of the value is returned
> we terminate the psql process.
>
> 2) Doing the same thing as above but in single process using readline
> callbacks(only supports --with-readline)
>

Yes, it's true that if the connection breaks, the client may not notice
that until the next command. But why would we want to kill psql in that
case? How does that improve the user experience?

If you're in an interactive session (which is where this matters), and
you're not running any commands, you're most likely not paying any
attention to it. So if psql terminates, you won't notice that either. It
doesn't change anything.

Also, it's a long-standing behavior that it the connection closes, I can
simply repeat the query and it's automatically re-opened.

test=# select 1;
FATAL: terminating connection due to administrator command
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.
test=# select 1;
?column?
----------
1
(1 row)

If we just kill psql instead, this won't work anymore. Why would that be
better?

Also, just killing the process (no matter if by kill or exit), this
means the usual cleanup doesn't happen. So stuff is not written to
.psql_history, for example. That doesn't seem great.

Overall, I don't quite see why the current behavior is a problem, and/or
why would this be an improvement.

thanks

--
Tomas Vondra