Received: from localhost (uranus.hub.org [200.46.204.60]) by postgresql.org (Postfix) with ESMTP id CAC529F9D99 for ; Thu, 16 Nov 2006 13:27:42 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.60]) (amavisd-new, port 10024) with ESMTP id 24468-10 for ; Thu, 16 Nov 2006 13:27:40 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.metronet.co.uk (mail.metronet.co.uk [213.162.97.75]) by postgresql.org (Postfix) with ESMTP id 76C009F946B for ; Thu, 16 Nov 2006 13:27:40 -0400 (AST) Received: from mainbox.archonet.com (84-51-143-99.archon037.adsl.metronet.co.uk [84.51.143.99]) by smtp.metronet.co.uk (MetroNet Mail) with ESMTP id DE3B073859; Thu, 16 Nov 2006 17:27:19 +0000 (GMT) Received: from [192.168.1.17] (client17.office.archonet.com [192.168.1.17]) by mainbox.archonet.com (Postfix) with ESMTP id DB55D15EAB; Thu, 16 Nov 2006 17:27:18 +0000 (GMT) Message-ID: <455CA016.7030709@archonet.com> Date: Thu, 16 Nov 2006 17:29:58 +0000 From: Richard Huxton User-Agent: Thunderbird 1.5.0.7 (X11/20060918) MIME-Version: 1.0 To: "Craig A. James" Cc: Russell Smith , pgsql-performance@postgresql.org Subject: Re: Postgres server crash References: <20061023215913.GW26892@nasby.net> <20061025001709.GA26892@nasby.net> <453EF7C4.2040105@modgraph-usa.com> <455BCAE8.8010905@modgraph-usa.com> <455BCCCD.2020701@pws.com.au> <455C420D.8090209@archonet.com> <455C9CCA.7080804@modgraph-usa.com> In-Reply-To: <455C9CCA.7080804@modgraph-usa.com> 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: 200611/123 X-Sequence-Number: 21893 Craig A. James wrote: > By the way, in spite of my questions and concerns, I was *very* > impressed by the recovery process. I know it might seem like old hat to > you guys to watch the WAL in action, and I know on a theoretical level > it's supposed to work, but watching it recover 150 separate databases, > and find and fix a couple of problems was very impressive. It gives me > great confidence that I made the right choice to use Postgres. > > Richard Huxton wrote: >>>> 2. Why didn't the database recover? Why are there two processes >>>> that couldn't be killed? >> >> I'm guessing it didn't recover *because* there were two processes that >> couldn't be killed. Responsibility for that falls to the >> operating-system. I've seen it most often with faulty drivers or >> hardware that's being communicated with/written to. However, see below. > > It can't be a coincidence that these were the only two processes in a > SELECT operation. Does the server disable signals at critical points? If a "kill -9" as root doesn't get rid of them, I think I'm right in saying that it's a kernel-level problem rather than something else. -- Richard Huxton Archonet Ltd