Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id B11BE9FB250 for ; Tue, 10 Oct 2006 13:10:36 -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 39134-02 for ; Tue, 10 Oct 2006 13:10:32 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from lynet.oppetid.no (oppetid.no [80.65.51.2]) by postgresql.org (Postfix) with ESMTP id AACB69FB24D for ; Tue, 10 Oct 2006 13:10:32 -0300 (ADT) Received: by lynet.oppetid.no (Postfix, from userid 1019) id D68E4119EF0; Tue, 10 Oct 2006 18:10:27 +0200 (CEST) Date: Tue, 10 Oct 2006 18:10:27 +0200 From: Tobias Brox To: pgsql-performance@postgresql.org Subject: long running transactions Message-ID: <20061010161027.GA18908@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-Spam-Status: No, hits=0.174 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200610/191 X-Sequence-Number: 21320 While doing a verbose vacuum, I'm constantly hitting things like: DETAIL: 3606 dead row versions cannot be removed yet. I believe this is a problem, because I still do have some empty tables requireing up to 3-400 ms just to check if the table is empty (see thread "slow queue-like empty table"). If pg_stat_activity.query_start actually is the start time of the transaction, then we've gotten rid of all the real long-running transactions. Then again, if pg_stat_activity.query_start actually was the start time of the transaction, the attribute would have been called pg_stat_activity.transaction_start, right? Is there any way to find the longest running transaction?