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 1hOp06-0003Nd-EY for pgsql-admin@arkaria.postgresql.org; Thu, 09 May 2019 19:46:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hOp04-0002i0-CC for pgsql-admin@arkaria.postgresql.org; Thu, 09 May 2019 19:46:40 +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 1hOp03-0002hp-Tx; Thu, 09 May 2019 19:46:40 +0000 Received: from smtp-fw-4101.amazon.com ([72.21.198.25]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hOp00-0002QW-TG; Thu, 09 May 2019 19:46:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1557431196; x=1588967196; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=npZm3OR1GyBfRg8N9eGBv7ptqpB9PDkumktpd4OKMw0=; b=FFvnzcMc2DGpoJdxKPR8zliUey/3iCueEqvnE7mNYRrXcTrQ4w31vt/K XFNPcKvKydebzqB/N7MLSneBKX9JeoQXyGubB5uYkODwJSbTvl8EuSyCm l0DMzbBQkfpESnxqP6TL0sjYP/9VxZP5Rrpj2+LT0TGTpHIIG4iHedrMG Y=; X-IronPort-AV: E=Sophos;i="5.60,450,1549929600"; d="scan'208";a="765481090" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2c-4e7c8266.us-west-2.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 May 2019 19:46:34 +0000 Received: from EX13MTAUWA001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-2c-4e7c8266.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id x49JkXPY117618 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 May 2019 19:46:33 GMT Received: from EX13D18UWA002.ant.amazon.com (10.43.160.199) by EX13MTAUWA001.ant.amazon.com (10.43.160.118) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 9 May 2019 19:46:33 +0000 Received: from 186590ce269b.ant.amazon.com (10.43.162.38) by EX13D18UWA002.ant.amazon.com (10.43.160.199) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 9 May 2019 19:46:33 +0000 Subject: Re: Query on pg_stat_activity table got stuck To: Tom Lane , neeraj kumar CC: , References: <15877.1557178386@sss.pgh.pa.us> <21502.1557339176@sss.pgh.pa.us> <29660.1557352732@sss.pgh.pa.us> From: Jeremy Schneider Message-ID: Date: Thu, 9 May 2019 12:46:32 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <29660.1557352732@sss.pgh.pa.us> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.43.162.38] X-ClientProxiedBy: EX13D25UWC004.ant.amazon.com (10.43.162.201) To EX13D18UWA002.ant.amazon.com (10.43.160.199) Precedence: Bulk List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 5/8/19 14:58, Tom Lane wrote: > 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? Crazy timing. We just had a report come in from a database in the RDS fleet that's hitting this same issue. It was one of the Aurora systems, but there wasn't anything Aurora-specific that I could see in the relevant bits of code. Seems to me that at a minimum, this loop shouldn't go on forever. Even having an arbitrary, crazy high, hard-coded number of attempts before failure (like a million) would be better than spinning on the CPU forever - which is what we are seeing. Would be even cooler to detect and correct a broken slot in PgBackendStatus... if I have a good idea I'll post/try it. :) -Jeremy -- Jeremy Schneider Database Engineer Amazon Web Services