Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id E778E9FB255 for ; Tue, 10 Apr 2007 19:50:47 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 33152-07 for ; Tue, 10 Apr 2007 19:50:40 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from lynet.oppetid.no (oppetid.no [80.65.51.2]) by postgresql.org (Postfix) with ESMTP id E09CC9FA605 for ; Tue, 10 Apr 2007 19:50:44 -0300 (ADT) Received: by lynet.oppetid.no (Postfix, from userid 1019) id CEFA811A751; Wed, 11 Apr 2007 00:50:37 +0200 (CEST) Date: Wed, 11 Apr 2007 00:50:37 +0200 From: Tobias Brox To: pgsql-performance Subject: Long running transactions again ... Message-ID: <20070410225037.GC19909@oppetid.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Group Nordicbet User-Agent: Mutt/1.5.9i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200704/239 X-Sequence-Number: 24116 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.