Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kLpSn-0002rG-59 for pgsql-bugs@arkaria.postgresql.org; Fri, 25 Sep 2020 15:16:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kLpSm-0001YC-31 for pgsql-bugs@arkaria.postgresql.org; Fri, 25 Sep 2020 15:16:44 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kLpSl-0001Y5-Oq for pgsql-bugs@lists.postgresql.org; Fri, 25 Sep 2020 15:16:43 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by magus.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kLpSj-0000ow-M3 for pgsql-bugs@lists.postgresql.org; Fri, 25 Sep 2020 15:16:43 +0000 Received: from [192.168.27.200] (unknown [93.174.131.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id 64A2B21C3925; Fri, 25 Sep 2020 18:16:40 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1601047000; bh=7tkZ1LW+wfBuQZ05i7Y+M0J6VIP1vJS9yRxf0bk5VEo=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=czX54gG9QiQI6PW7bqZZ7uMGe5sLVuoC+mc3qknKdZrwKS8woBHNoaRm9x26BnG3L Ak79Hzk3j4aG1tGW0EpNKDWaw71sZrHS7CkjNZo7lzNM5XNtH982TFTROT069sGRq4 mLl3I5Eqy4WGBNzKTf4JKlfojKDqOnaRq4bjc7G0= Subject: Re: Memory leak in RelationBuildRowSecurity To: Tom Lane Cc: pgsql-bugs@lists.postgresql.org References: <21356c12-8917-8249-b35f-1c447231922b@postgrespro.ru> <1852787.1601041699@sss.pgh.pa.us> From: Konstantin Knizhnik Message-ID: <3f670fa6-5e81-fbd9-b880-eaa275f15e1c@postgrespro.ru> Date: Fri, 25 Sep 2020 18:16:40 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <1852787.1601041699@sss.pgh.pa.us> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 25.09.2020 16:48, Tom Lane wrote: > Konstantin Knizhnik writes: >> There is memory leak in RelationBuildRowSecurity function - it converts >> node to expression tree in current memory context: > Hm ... this smells a whole lot like the issue we fixed recently for > partition expressions, namely: what the devil are we doing reloading > these expressions during RelationClearRelation? We should delay > populating that cache until the value is requested. Sorry, this stack trace was obtained at 9.6 version of Postgres which the customer is using. So may be the problem with cache invalidation is already fixed. But the memory leak in RelationBuildRowSecurity is still present. May be it is not so critical if RelationBuildRowSecurity will not be called many times in the same memory context. But at least calling pfree for a tree is very strange idea: we should not do it all or allocate tree in separate memory context. By the way - it is illustration how "SQL function data" is growing after each invocation of RelationBuildRowSecurity: SQL function data: 57344 total in 3 blocks; 53112 free (278 chunks); 4232 used SQL function data: 289213248 total in 3137 blocks; 3281544 free (217 chunks); 285931704 used SQL function data: 578434688 total in 6265 blocks; 6581320 free (234 chunks); 571853368 used SQL function data: 1148488960 total in 12520 blocks; 4793680 free (17 chunks); 1143695280 used SQL function data: 2288597504 total in 25030 blocks; 1222064 free (221 chunks); 2287375440 used