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 1hOUaa-00060p-1J for pgsql-general@arkaria.postgresql.org; Wed, 08 May 2019 21:59:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hOUaY-0003lo-Fa for pgsql-general@arkaria.postgresql.org; Wed, 08 May 2019 21:58:58 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hOUaX-0003if-OS; Wed, 08 May 2019 21:58:57 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hOUaV-0005lc-7C; Wed, 08 May 2019 21:58:56 +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 x48LwqB3029661; Wed, 8 May 2019 17:58:52 -0400 From: Tom Lane To: neeraj kumar cc: pgsql-admin@postgresql.org, pgsql-general@postgresql.org Subject: Re: Query on pg_stat_activity table got stuck In-reply-to: References: <15877.1557178386@sss.pgh.pa.us> <21502.1557339176@sss.pgh.pa.us> Comments: In-reply-to neeraj kumar message dated "Wed, 08 May 2019 14:21:06 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29659.1557352732.1@sss.pgh.pa.us> Date: Wed, 08 May 2019 17:58:52 -0400 Message-ID: <29660.1557352732@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk neeraj kumar writes: > Yes we use SSL to connect to DB. Hm. I'm suspicious that one of the functions that fetch data for an SSL connection threw an error. In particular, it doesn't look to be hard at all to make X509_NAME_to_cstring fall over --- an encoding conversion failure would do it, even without any stretchy assumptions about OOM this early in backend start. Have you got any SSL certificates floating around with non-ASCII subject name or issuer name? > From comment seems like each backend should have its own copy > of PgBackendStatus, it means st_changecount should be different for each > process. If st_changecount was corrupted for 1/2 process, how can it impact > newly created process. So could you please help to understand then how come > if we run new query via new console (means new process) that also is > getting stuck. No, that field is in shared memory. The easiest way to get it reset would be to restart the postmaster. It's possible you could do it without that, by starting enough sessions so that one of them takes up the broken pg_stat_activity slot. regards, tom lane