Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1frsWS-0001rM-JZ for pgsql-performance@arkaria.postgresql.org; Mon, 20 Aug 2018 22:19:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1frsWN-0002ju-PW for pgsql-performance@arkaria.postgresql.org; Mon, 20 Aug 2018 22:19:35 +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.89) (envelope-from ) id 1frsWN-0002jk-CZ for pgsql-performance@lists.postgresql.org; Mon, 20 Aug 2018 22:19:35 +0000 Received: from smtp-fw-6002.amazon.com ([52.95.49.90]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1frsWF-0006Fv-T6 for pgsql-performance@lists.postgresql.org; Mon, 20 Aug 2018 22:19:33 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1534803567; x=1566339567; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=yZL7gPO4xZ6LaCSPvcXgKjc0IrXFUZsOOInEJuKweUw=; b=Zz8w5nSM3dNEJHaFcDnrNobwpE2dkaqtZnGZkEci9udHDW1ojyFuf/bK IeANECTeW7RSLCJoBs3WszPCt0pRotFA8a319rKbaEuy05j2KdiCxNTmE /hJmmYdmJXy/8okJkitffrbIppWM7UTnVywQ+fgQESBU8Gq0PnxE1GOBw c=; X-IronPort-AV: E=Sophos;i="5.53,266,1531785600"; d="scan'208";a="358271332" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2c-579b7f5b.us-west-2.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Aug 2018 22:16:47 +0000 Received: from EX13MTAUWA001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-2c-579b7f5b.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id w7KMErws106228 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 Aug 2018 22:14:54 GMT Received: from EX13D18UWA002.ant.amazon.com (10.43.160.199) by EX13MTAUWA001.ant.amazon.com (10.43.160.58) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 20 Aug 2018 22:14:49 +0000 Received: from 186590ce269b.ant.amazon.com (10.43.160.160) by EX13D18UWA002.ant.amazon.com (10.43.160.199) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 20 Aug 2018 22:14:49 +0000 Subject: Re: Guideline To Resolve LWLock:SubtransControlLock To: Fred Habash CC: References: <20180816183632.lo34je5dudbros4a@alvherre.pgsql> From: Jeremy Schneider Message-ID: <473e3dba-f052-23df-6f04-6df208220205@amazon.com> Date: Mon, 20 Aug 2018 15:14:49 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.43.160.160] X-ClientProxiedBy: EX13D16UWB002.ant.amazon.com (10.43.161.234) To EX13D18UWA002.ant.amazon.com (10.43.160.199) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 8/17/18 11:07, Fred Habash wrote: > Aurora Postgres 9.6.3 Hi Fred! The Amazon team does watch the AWS forums and that's the place to raise questions that are specific to PostgreSQL on RDS or questions specific to Aurora. In fact we would love to see this question over there since it might be something other people see as well. https://forums.aws.amazon.com/forum.jspa?forumID=227 That said... FWIW, Aurora PostgreSQL version 9.6.3 uses parent/child transaction relationships pretty much the same way that community PostgreSQL 9.6.3 does. The uses you pointed out (savepoints and exceptions in plpgsql) are the most common causes of contention I've seen - similar to what Alvaro said his experience is. I have seen applications grind to a halt on SubtransControlLock when they make heavy use of exception blocks in plpgsql code; in fact it's pretty straightforward to demonstrate this behavior with pgbench on community PostgreSQL. On 8/20/18 14:00, Alvaro Herrera wrote: >> And do both require a recompile? > > Yes. But maybe they'll just move the contention point a little bit > backwards without actually fixing anything. When it comes to resolution, I agree with Alvaro's assessment here; unfortunately, I don't know of a great solution on community PostgreSQL outside of trying to reduce the use of exception blocks in your plpgsql code. Increasing the cache size can give a little more head room but doesn't move the contention point significantly. That single global control lock is hard to get around when you try to use subtransactions at scale. -Jeremy P.S. This applies on the Aurora PostgreSQL 9.6.3 build too but I'm discussing here in the context of community PostgreSQL code and we can put further Aurora-specific discussion on the AWS forums. -- Jeremy Schneider Database Engineer Amazon Web Services