From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | dastapov(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17698: On SIGTERM, psql terminates, but leaves the statement running |
Date: | 2023-01-16 15:14:59 |
Message-ID: | 20230116151459.fzg6mlegkcrzch4i@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 2022-Nov-25, PG Bug reporting form wrote:
> Reproduction: start psql, launch a query that will take a while (I
> used 'select pg_sleep(1234)'), then from another terminal do
> "kill -TERM <pid of psql>". Psql would be terminated, but query would
> not be, and will keep running until TCP timeout kicks in and kills the
> stale connection.
>
> SIGINT, on the other hand, will cause psql will terminate the current
> statement.
>
> Perhaps psql could have a SIGTERM handler that does roughly what
> SIGINT handler does before terminating the whole process, and would
> cancel the current statement (if any)?
Sure. I doubt we want to wait until a reply to the cancel request is
obtained, but we could have the sigterm handler at least send it before
terminating.
Why do you send SIGTERM to psql anyway?
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end." (2nd Commandment for C programmers)
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2023-01-16 15:31:04 | Re: BUG #17741: vacuum process hangs after pg_surgery manipulations |
Previous Message | Mats Kindahl | 2023-01-16 10:09:47 | Re: Crash during backend start when low on memory |