From: | "Tristan Partin" <tristan(at)neon(dot)tech> |
---|---|
To: | "Alvaro Herrera" <alvherre(at)alvh(dot)no-ip(dot)org>, <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-05-22 17:04:58 |
Message-ID: | CSSYXFI3JCDF.1RO2ES99IT2GH@c3po |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon Jan 16, 2023 at 9:14 AM CST, Alvaro Herrera wrote:
> 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.
I am currently working on a patch for this.
--
Tristan Partin
Neon (https://neon.tech)
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2023-05-22 18:10:43 | BUG #17938: could not open shared memory segment "/PostgreSQL.615216676": No such file or directory |
Previous Message | David G. Johnston | 2023-05-22 13:42:52 | Re: How to restore database without re-write database and tables owner by using postgres |