X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 8AACA9FB1C7 for ; Fri, 14 Jul 2006 13:18:38 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 37570-10 for ; Fri, 14 Jul 2006 13:18:33 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from moonunit2.moonview.localnet (wsip-70-167-125-69.sd.sd.cox.net [70.167.125.69]) by postgresql.org (Postfix) with ESMTP id 0500D9FB1C4 for ; Fri, 14 Jul 2006 13:18:32 -0300 (ADT) Received: from [192.168.0.3] (moonunit3.moonview.localnet [192.168.0.3]) by moonunit2.moonview.localnet (8.13.1/8.13.1) with ESMTP id k6EGYCg1009144; Fri, 14 Jul 2006 09:34:12 -0700 Message-ID: <44B7B592.1090405@modgraph-usa.com> Date: Fri, 14 Jul 2006 08:17:38 -0700 From: "Craig A. James" User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Tom Lane CC: pgsql-performance@postgresql.org, sgunderson@bigfoot.com Subject: Re: Kill a session References: <6BCB9D8A16AC4241919521715F4D8BCEA0FAE8@algol.sollentuna.se> <44B51896.1000808@modgraph-usa.com> <20060712170404.GA27392@uio.no> <44B70017.6000703@modgraph-usa.com> <8780.1152856222@sss.pgh.pa.us> In-Reply-To: <8780.1152856222@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200607/143 X-Sequence-Number: 20003 Tom Lane wrote: > "Craig A. James" writes: >> Bottom line is that I was expecting "instant death" with SIGTERM, but >> instead got an agonizing, drawn out -- but safe -- death of the query. > > What was the query exactly? > > Our expectation is that all or at least most queries should respond to > SIGINT or SIGTERM interrupts pretty rapidly, say on a less-than-a-second > timescale. However there are various loops in the backend that fail to > execute CHECK_FOR_INTERRUPTS sufficiently often :-(. We've been > gradually finding and fixing these, and will be glad to fix your case > if you provide enough details to pin it down. You might be interested > in this current thread about a similar problem: > > http://archives.postgresql.org/pgsql-patches/2006-07/msg00039.php Thanks, this is good information. The qsort is a distinct possibility. The query is a big insert into some_hitlist (select id from another_hitlist join data_table on (...)) where the hitlists are unindexed. So it may be using a merge-join with qsort. When I have a few minutes, I'll turn on logging in the app and find the exact SQL, and run an EXPLAIN ANALYZE and see what's really happening. It's also possible that the INSERT itself is the problem, or adds to the problem. The SIGINT may come after a few million rows have been inserted, so it would have to clean that up, right? Thanks, Craig