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 1ihcDs-0004Zg-KU for pgsql-bugs@arkaria.postgresql.org; Wed, 18 Dec 2019 16:30:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ihcDq-00083w-VI for pgsql-bugs@arkaria.postgresql.org; Wed, 18 Dec 2019 16:30:50 +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 1ihcDq-00083p-NC for pgsql-bugs@lists.postgresql.org; Wed, 18 Dec 2019 16:30:50 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ihcDo-0001n9-EJ for pgsql-bugs@postgresql.org; Wed, 18 Dec 2019 16:30:50 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id xBIGUhMn005856; Wed, 18 Dec 2019 11:30:43 -0500 From: Tom Lane To: depesz@depesz.com cc: Kaijiang Chen , Pg Bugs Subject: Re: Fwd: weird long time query In-reply-to: <20191218162349.GA11569@depesz.com> References: <20191218140631.GA1083@depesz.com> <20191218162349.GA11569@depesz.com> Comments: In-reply-to hubert depesz lubaczewski message dated "Wed, 18 Dec 2019 17:23:49 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5854.1576686643.1@sss.pgh.pa.us> Date: Wed, 18 Dec 2019 11:30:43 -0500 Message-ID: <5855.1576686643@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk hubert depesz lubaczewski writes: > On Thu, Dec 19, 2019 at 12:14:26AM +0800, Kaijiang Chen wrote: >> BTW, I got the similar result (still see that proc) with "select * from >> pg_stat_activity": >> ... >> state | idle >> ... >> query | DEALLOCATE pdo_stmt_00000388 >> >> Looks not very nice :-) > not sure what you mean by not nice. That's a feature not a bug (and yes, the behavior is documented). People requested that the view continue to display the last query of an idle session. IIRC, the main argument was that otherwise it's hard to tell apart a bunch of idle sessions. If you don't like it, you can always do something like case when state = idle then null else query end regards, tom lane