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 1peEDc-0003XO-8h for pgsql-bugs@arkaria.postgresql.org; Mon, 20 Mar 2023 12:02:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1peEDb-0008Lq-4l for pgsql-bugs@arkaria.postgresql.org; Mon, 20 Mar 2023 12:02:27 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pe8vS-0008Dj-Nk for pgsql-bugs@lists.postgresql.org; Mon, 20 Mar 2023 06:23:22 +0000 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pe8vQ-0006L0-59 for pgsql-bugs@lists.postgresql.org; Mon, 20 Mar 2023 06:23:21 +0000 Received: by mail-ed1-x535.google.com with SMTP id eg48so42254227edb.13 for ; Sun, 19 Mar 2023 23:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataegret-com.20210112.gappssmtp.com; s=20210112; t=1679293398; h=content-language:content-transfer-encoding:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject:from:to:cc :subject:date:message-id:reply-to; bh=tUNtKR5AUMAqLUNb7MevAk6yc6eCQkc324lZEp1kYik=; b=bopuMcB2zPvmvhyA3Hfo0DJr8nVRNx4akOIz3N98QQOQIiKzum8j3gk0V1M+DzRfRz sso1LqaAFxGRsy3G8/af69mSsCOcUU83FNRBn7R5f0OZbyyeSk1UgsHIOOL/V92MMV5X SAEqNo+xcBq9r+TOa8TshLO38vHp+fi6IzakOzy3qRNEWL790ctvT/fRW8zA/yG+sQru rK/ROnK2BL2uzxaxFF1seKtwjx1o5KVf5zJJZio8hmQ25yEfjJYUWRrUUh4dYwTBIB1N JPQWD/ApKnzS+8jKKrsnA93CTEdK5yEyRBl06PQTHC9BckA4sFyy0n49f7ym3Md/X7rE 0Krg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679293398; h=content-language:content-transfer-encoding:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=tUNtKR5AUMAqLUNb7MevAk6yc6eCQkc324lZEp1kYik=; b=salNOMvuVAtea5LRtgC2lLjEfHef+PrIVv0DEV7mYI9RcKIEnHZartRRm5b5jfJivY 71P6wqSYB9SX6AlDGmlHsB48XwVjnhGzsT+DWjbvrWz2+Sblfj+U8YP6Lpvm1pVmgZmu k4vRIXOiItRdj7PJx2QsOQt2rTGLn1wkx8PFHVT/JiNkxUa5+EbbOSGbWkTpBQBpjOsH NMdSYxSVl+KhSltLu7eniCVc/dfqDnWkl6XxjqLZaYIeiOeMP7rPc4V59Hkd1nWbgAws SZ11UTCMyrf5NKWsV9SOFYTSg94f3Yor0hy4tf6jqQsDkniNgnMm+v0HkN0zHWBBObsi qD+Q== X-Gm-Message-State: AO0yUKUCjzLrJtsQ1gqXYNLuv56hX83ZRUpcpTJH+kuca5VxYlIIhkNk nQDqAHiXePa1T3cq5AsAzUEw6M4VpFKsLKObU7A= X-Google-Smtp-Source: AK7set9uI6r9TUyZuRut4FjQ54i3Mi2EoHHv8vJ7Ntf70MuX+4N5DEc2t4YTcMldK9NNzoh/cx390w== X-Received: by 2002:a05:6402:1247:b0:4fc:18ca:b57f with SMTP id l7-20020a056402124700b004fc18cab57fmr10171391edw.30.1679293398395; Sun, 19 Mar 2023 23:23:18 -0700 (PDT) Received: from Alexeys-MacBook-Pro.local ([62.118.85.30]) by smtp.googlemail.com with ESMTPSA id j30-20020a508a9e000000b004af5968cb3bsm4304620edj.17.2023.03.19.23.23.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Mar 2023 23:23:18 -0700 (PDT) Subject: Re: BUG #17844: Memory consumption for memoize node To: David Rowley , pgsql-bugs@lists.postgresql.org References: <17844-d2f6f9e75a622bed@postgresql.org> From: Alexey Ermakov Message-ID: Date: Mon, 20 Mar 2023 12:23:11 +0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: 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: Archived-At: Precedence: bulk On 2023-03-19 15:33, David Rowley wrote: > On Sat, 18 Mar 2023 at 13:22, David Rowley wrote: >> It seems to be related to a bug in nodeMemoize.c where we're >> evaluating the cache key expressions in the ExecutorState context. We >> should really be in a more temporary context that gets reset early in >> cache_lookup() before the call to prepare_probe_slot(). I'll need to >> look in a bit more detail about what that context actually should be. > I've attached fix_memoize_memory_leak.patch to address this. > > Using your test case, here are the memory stats before and after the > fix (taken during ExecEndMemoize). > Thanks a lot! Could you please point me in the direction how to get such memory stats ? I might know another memory leak I'd like to check but sadly I don't know right tools to measure memory usage. -- Thanks, Alexey Ermakov