Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ihc78-0004CP-9i for pgsql-bugs@arkaria.postgresql.org; Wed, 18 Dec 2019 16:23:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ihc76-0003bV-T7 for pgsql-bugs@arkaria.postgresql.org; Wed, 18 Dec 2019 16:23:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ihc76-0003bO-Ii for pgsql-bugs@lists.postgresql.org; Wed, 18 Dec 2019 16:23:52 +0000 Received: from lana.depesz.com ([88.198.49.178] helo=depesz.com) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ihc74-0001jg-Bw for pgsql-bugs@postgresql.org; Wed, 18 Dec 2019 16:23:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=depesz.com; s=20170201; h=In-Reply-To:Content-Type:MIME-Version:References:Reply-To: Message-ID:Subject:Cc:To:Sender:From:Date:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=t1+ucPl6OoWdnIb35BFQRDNJiBVY/faH6GNBJiwVgG4=; b=Ut9u0oX/yUaBBtM3bkcXi8Wqhu M4FZzIZGDhtIoi0Hsspbp8fp22NKdCKVJlvVmQmu4ap7878v5bm7XBKHp8zLR4VS///CVnvaN92IH R4CBRelfTe/jO9GpIEYH+wZqHMK47b+y3w99J7CFtn7HzJYP3CgR8KNtzNzFAoeqVyBM=; Received: from lana.depesz.com ([88.198.49.178] helo=depesz.com) by depesz.com with esmtpa (Exim 4.92) (envelope-from ) id 1ihc73-0003ia-BL; Wed, 18 Dec 2019 17:23:49 +0100 Date: Wed, 18 Dec 2019 17:23:49 +0100 From: hubert depesz lubaczewski Sender: depesz@depesz.com To: Kaijiang Chen Cc: Pg Bugs Subject: Re: Fwd: weird long time query Message-ID: <20191218162349.GA11569@depesz.com> Reply-To: depesz@depesz.com References: <20191218140631.GA1083@depesz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, Dec 19, 2019 at 12:14:26AM +0800, Kaijiang Chen wrote: > Thanks! > I learn the SQL from the web. pg views should be better. > BTW, I got the similar result (still see that proc) with "select * from > pg_stat_activity": > > backend_start | 2019-11-25 16:27:05.103901+08 > xact_start | > query_start | 2019-11-25 16:29:29.529318+08 > state_change | 2019-11-25 16:29:29.529344+08 > waiting | f > state | idle > backend_xid | > backend_xmin | > query | DEALLOCATE pdo_stmt_00000388 > > Looks not very nice :-) not sure what you mean by not nice. As you can clearly see the backend is *NOT* running anything (state is idle). Value in "query" column is simply last query that it ran. It *finished* running this query at 2019-11-25 16:29:29.529344+08. So your app is keeping connection open. It's not Pg problem or a bug. Best regards, depesz