Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id E9AAE9FB2E5 for ; Wed, 18 Apr 2007 15:26:00 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 33583-01 for ; Wed, 18 Apr 2007 15:25:56 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id 931A79FB1B9 for ; Wed, 18 Apr 2007 15:25:57 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id A32EC564A5; Wed, 18 Apr 2007 13:25:56 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Wed, 18 Apr 2007 13:25:53 -0500 Date: Wed, 18 Apr 2007 13:25:53 -0500 From: "Jim C. Nasby" To: Tobias Brox Cc: pgsql-performance Subject: Re: Long running transactions again ... Message-ID: <20070418182553.GX72669@nasby.net> References: <20070410225037.GC19909@oppetid.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070410225037.GC19909@oppetid.no> X-Operating-System: FreeBSD 6.1-RELEASE-p10 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.13 (2006-08-11) X-Hashcash: 1:20:070418:tobias@nordicbet.com::g2Id1of44fs7L2fJ:00000000000000000 000000000000000000000000720n X-Hashcash: 1:20:070418:pgsql-performance@postgresql.org::WNl6e8+mRPL46XAm:00000 000000000000000000000000ATA5 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200704/338 X-Sequence-Number: 24215 On Wed, Apr 11, 2007 at 12:50:37AM +0200, Tobias Brox wrote: > We had problems again, caused by long running transactions. I'm > monitoring the pg_stat_activity view, checking the query_start of all > requests that are not idle - but this one slipped under the radar as the > application was running frequent queries towards the database. > > That's not what concerns me most. We had two databases running under > postgres at this host - like, main production database (A) and a > separate smaller database for a separate project (B). As far as I > understood postgres philosophy, the databases should be isolated from > each other, i.e. one are not allowed to create a query that goes across > the database borders (select * from A.customers join B.logins ...). So, > I was surprised to see that the application working towards database B > managed to jam up database A, to the extent that we couldn't get A > vacuumed properly. Vacuums do ignore other databases, except for shared relations such as pg_database. If one of the databases wasn't being vacuumed properly it means there was in fact a transaction open. Note that until recently, vacuums wouldn't ignore other vacuums, so a long-running vacuum would prevent repeated vacuums on the same table from accomplishing much. Are you sure that your monitoring doesn't accidentally ignore backends marked as in transaction? -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)