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 E1BBD9FB35B for ; Fri, 14 Jul 2006 08:28:24 -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 78425-05 for ; Fri, 14 Jul 2006 08:28:14 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.logix-tt.com (mail.logix-tt.com [212.211.145.186]) by postgresql.org (Postfix) with ESMTP id 1F30F9FB352 for ; Fri, 14 Jul 2006 08:28:14 -0300 (ADT) Received: from kingfisher.intern.logix-tt.com (T9049.t.pppool.de [89.55.144.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.logix-tt.com (Postfix) with ESMTP id AC3B7656BB for ; Fri, 14 Jul 2006 13:29:52 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by kingfisher.intern.logix-tt.com (Postfix) with ESMTP id 94A33185B293B for ; Fri, 14 Jul 2006 13:28:29 +0200 (CEST) Message-ID: <44B77FDD.2000900@logix-tt.com> Date: Fri, 14 Jul 2006 13:28:29 +0200 From: Markus Schaber Organization: Logical Tracking and Tracing International AG, Switzerland User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: pgsql-performance@postgresql.org 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> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200607/142 X-Sequence-Number: 20002 Hi, Tom, Tom Lane wrote: > 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 :-(. The same is true for user-defined C funtions. The PostGIS GEOS geometry functions come to mind, for complex geometries, they can need hours to complete. And as GEOS is a 3rd-Party library, I don't see an easy way to make them CHECK_FOR_INTERRUPTS. Does anybody know how this is for plpgsql, pljava and plpython? HTH, Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org