From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: killing pg_dump leaves backend process |
Date: | 2013-08-11 20:25:43 |
Message-ID: | 5207F347.9040709@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 08/10/2013 04:26 AM, Greg Stark wrote:
> On Sat, Aug 10, 2013 at 5:30 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.
I've been waiting forever to have something we can justifiably call the
"loner suicide patch". ;-)
> I'm surprised this is the first time we're hearing people complain
> about this. I know I've seen similar behaviour from Mysql and thought
> to myself that represented pretty poor behaviour and assumed Postgres
> did better.
No, it's been a chronic issue since we got SMP support, pretty much
forever. Why do you think we have pg_terminate_backend()?
The problem, as explored downthread, is that there's no clear way to fix
this. It's a problem which goes pretty far beyond PostgreSQL; you can
experience the same issue on Apache with stuck downloads.
Our advantage over MySQL is that the idle process isn't likely to crash
anything ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2013-08-11 21:01:13 | Re: Replication delay |
Previous Message | ascot.moss@gmail.com | 2013-08-11 16:41:23 | Re: replication server: LOG: invalid magic number 0000 in log file 169, segment 77, offset 4325376 |