Re: killing pg_dump leaves backend process

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

In response to

Responses

Browse pgsql-hackers by date

  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