Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dYZhi-0002ZS-Bu for pgsql-sql@arkaria.postgresql.org; Fri, 21 Jul 2017 15:18:58 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dYZhh-0002FU-Uq for pgsql-sql@arkaria.postgresql.org; Fri, 21 Jul 2017 15:18:57 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dYZhf-00026T-Fz for pgsql-sql@postgresql.org; Fri, 21 Jul 2017 15:18:55 +0000 Received: from mail-wr0-x22d.google.com ([2a00:1450:400c:c0c::22d]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dYZhc-0003Fd-Se for pgsql-sql@postgresql.org; Fri, 21 Jul 2017 15:18:54 +0000 Received: by mail-wr0-x22d.google.com with SMTP id v105so53538853wrb.0 for ; Fri, 21 Jul 2017 08:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=tFUHl8KR1IfWxJD44YArxhYnECzTjBrr5q3G5SAiicQ=; b=uUJsCKTcuar09ckCV67ybzF1lZzge2hT2pvr8wQYDDVWle3ddFf87HdboQKbULfldh GFr1bvR7omyOLzbb7ykdwzgCavGIK9+nbR/ZLdZaDlxdNDjRkWnDOmp2wTbNImFWV+SB QvNVknpeTArqdISY9XNZBhhdvSphCUso2CYcerIqbgbvkUHMkQrE4HzDTnqRgqP3S8JP lO9C4laQXhuEN9Kh+YZ+ti1FPy6fbjZNjh5CETNou+mH/urPj36rhnBO81Qexmk90Yrs eMl/p5r2wXof6wTao5H7dpznENgG+Fhn6gNFmTupGXOSf5u7bflLheObmghHam51wtwF mSTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=tFUHl8KR1IfWxJD44YArxhYnECzTjBrr5q3G5SAiicQ=; b=JCUCVmjnVYKxcINdGlXtRCbRh00KiWCgbFZezUzGerj1V5bf6Y/Q7mftJiq5coV26y tu9/4qucJjfyJvkIXHXRoI+XolmEspFIDMeNk3yyg2+dJxh6CKbGUbcylIhj8FOnR+LX a+varTrZoJ1DMjVigPlcR90A6LTfxB8gC8LT7DuXTLshVjXR992GCoutIksYxC4eOiYq RXwV4DgxsLzuQG4iauNnJvxaD8M5IQWqqWT3/o9LEoqTejK90dl3vWz7/71EZnUgG3nf LjUmS2SPTeSBprMSvwhbcCXxWSd3TfZZinjOmH1jNubDtLrbv9d8SmfoB7Keyba1YMM3 b88A== X-Gm-Message-State: AIVw113d9CrUqIXkuCbH4kZ2wozywThpMC77qrA7Jgm4heJSbJGp94tf cyTUtxiJ9rOCVGVl X-Received: by 10.223.177.158 with SMTP id q30mr11356583wra.123.1500650331258; Fri, 21 Jul 2017 08:18:51 -0700 (PDT) Received: from timbomac.domain_not_set.invalid ([88.202.149.90]) by smtp.googlemail.com with ESMTPSA id 94sm14378235wrb.55.2017.07.21.08.18.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jul 2017 08:18:50 -0700 (PDT) Subject: Re: commit not completing - how to investigate? To: pgsql-sql@postgresql.org References: <5e59f5e0-7168-fb80-d038-7fe9adad4aa9@gmail.com> <29711.1500646472@sss.pgh.pa.us> From: Tim Dudgeon Message-ID: Date: Fri, 21 Jul 2017 16:18:49 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <29711.1500646472@sss.pgh.pa.us> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-sql Precedence: bulk Sender: pgsql-sql-owner@postgresql.org Maybe I'm not interpreting it correctly. I was assuming that if the view reported a row then that row was still "happening". Yes, the state is "idle", and the command is "COMMIT". But if the COMMIT has completed then the process should finish and the row not be present? So is what you are suggesting that in my case I'm using a connection pool, and the COMMIT has completed successfully, the connection released back to the pool, but not yet closed, so that process is still running? Tim On 21/07/2017 15:14, Tom Lane wrote: > Tim Dudgeon writes: >> I have a situation where the pg_stat_activity view shows that can have >> some processes that are idle and not completing. In some cases the >> statement being executed is COMMIT. > Are you sure you're interpreting the view properly? If the session > state is shown as idle, it's idle. We used to show the query field > as empty in that case, but recent PG versions allow the query field > to continue to show the last-completed command. > > regards, tom lane -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql