X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 45C449DC809 for ; Thu, 29 Dec 2005 23:03:04 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 60871-03 for ; Thu, 29 Dec 2005 23:03:08 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 292F49DC841 for ; Thu, 29 Dec 2005 23:03:01 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id jBU331uZ007578; Thu, 29 Dec 2005 22:03:01 -0500 (EST) To: Russ Garrett cc: "Jeffrey W. Baker" , pgperf Subject: Re: Invulnerable VACUUM process thrashing everything In-reply-to: <43B468D7.2050806@garrett.co.uk> References: <1135894162.2223.4.camel@toonses.gghcwest.com> <6.2.5.6.0.20051229173718.01dbfff0@earthlink.net> <43B468D7.2050806@garrett.co.uk> Comments: In-reply-to Russ Garrett message dated "Thu, 29 Dec 2005 22:53:11 +0000" Date: Thu, 29 Dec 2005 22:03:01 -0500 Message-ID: <7577.1135911781@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.054 required=5 tests=[AWL=0.054] X-Spam-Score: 0.054 X-Spam-Level: X-Archive-Number: 200512/655 X-Sequence-Number: 16476 Russ Garrett writes: > VACUUM *will* respond to a SIGTERM, but it doesn't check very often - > I've often had to wait hours for it to determine that it's been killed, > and my tables aren't anywhere near 1TB. Maybe this is a place where > things could be improved... Hmm, there are CHECK_FOR_INTERRUPTS calls in all the loops that seem significant to me. Is there anything odd about your database schema? Unusual index types or data types maybe? Also, what PG version are you using? If you notice a VACUUM not responding to SIGTERM promptly, it'd be useful to attach to the backend process with gdb and get a stack trace to find out what it's doing. regards, tom lane