From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: killing pg_dump leaves backend process |
Date: | 2013-08-10 04:30:30 |
Message-ID: | 417.1376109030@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tatsuo Ishii <ishii(at)postgresql(dot)org> writes:
> I noticed pg_dump does not exit gracefully when killed.
> start pg_dump
> kill pg_dump by ctrl-c
> ps x
> 27246 ? Ds 96:02 postgres: t-ishii dbt3 [local] COPY
> 29920 ? S 0:00 sshd: ishii(at)pts/5
> 29921 pts/5 Ss 0:00 -bash
> 30172 ? Ss 0:00 postgres: t-ishii dbt3 [local] LOCK TABLE waiting
> As you can see, after killing pg_dump, a backend process is (LOCK
> TABLE waiting) left behind. I think this could be easily fixed by
> adding signal handler to pg_dump so that it catches the signal and
> issues a query cancel request.
If we think that's a problem (which I'm not convinced of) then pg_dump
is the wrong place to fix it. Any other client would behave the same
if it were killed while waiting for some backend query. So the right
fix would involve figuring out a way for the backend to kill itself
if the client connection goes away while it's waiting.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2013-08-10 04:36:06 | Re: Proposal: leave a hint when switching logging away from stderr |
Previous Message | Andres Freund | 2013-08-10 03:17:07 | Re: mvcc catalo gsnapshots and TopTransactionContext |