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 1q2CCA-0003TP-1s for pgsql-hackers@arkaria.postgresql.org; Thu, 25 May 2023 14:44:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1q2CC8-00039m-Ty for pgsql-hackers@arkaria.postgresql.org; Thu, 25 May 2023 14:44:00 +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 1q2CC8-00036y-KB for pgsql-hackers@lists.postgresql.org; Thu, 25 May 2023 14:44:00 +0000 Received: from mail-ed1-x52c.google.com ([2a00:1450:4864:20::52c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1q2CC4-0025X9-Tf for pgsql-hackers@lists.postgresql.org; Thu, 25 May 2023 14:43:59 +0000 Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-510dabb3989so4704051a12.0 for ; Thu, 25 May 2023 07:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1685025835; x=1687617835; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=D3UxvzVpQ4ixOc3S2kk8Ek4ZIsSCyJdzEkjLyxBa4xw=; b=LY8H1cQk4oPkih2gSVyF7wFGY6pMhF8NSMCKxb8wobUeEi+WtwJKXLbxcEl+lEw+Vu 9Q0B0WAH/bhJgEGYwS1IGzwHE7okIFCkMhAzjJnvRCtopXKBtOvK3XcPG2LqKc3fH5ia YKVb7S+d3cCgdL8GC2yYHV50us5T3DnHYM4BWaS67CH1UHtcPhoXrr/0PTVbkygH4yqR SjdnBKd/gVAWxoAUlHo1Xty3nQ+0p36hJ2X1KAmzKv7vXak05bVKZ9YipCs0tRu+jN0f dfegJBE4F458CYMr9H9QSwiCGPoBId8+dbP7b+381X7vfw+x0cow3bs7puiYWG0ryDFd rSSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685025835; x=1687617835; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=D3UxvzVpQ4ixOc3S2kk8Ek4ZIsSCyJdzEkjLyxBa4xw=; b=crGlU2mTKV7D0WeDQb7ZG2dfmNhfsqZl7ljb/Wq86/bNTV5Cbku3a4zULpf7tWDroW Gs72vHGLaHdAkNgPU3KiXQth9DKEscTA0Ay373JVrLHRWIbhh5zaq0SdhluYBrjUM3sK 7P6pE5Gm54IpQyIgQf3F5yzWcK9TYU0O38Zc/xiZRkM/Zua9rZxkLKC2sxCUS43P3WuZ 8XojWUbnO0tYiw4ic4hoYy8dM76WNF6rAzJxJCza6cmEFs5j/oFKDypz9vQCXO54TSNd k9l4r90yIl/+mFRCwo8ss2d+oOGZGIOry1kW3qlSA5UEw9TRRszBZaWefCjEv//GslUd jWhA== X-Gm-Message-State: AC+VfDyi654CVUhQo3AwJyMfMt+6+4lo+7IcP9Qu2oPN4SSikSct1PFn rtWapBDollUy6UZ2MZQ8qcGZd+m02nqIS0RxzpaVuTHhD2mnf4NyBsgh9eOcisl16ss//KPg6Gf ZuiAibONBpuNgAVxG0QLuT+yxzii4z60iHhwRqcjHJRMtq+ESjM6E0Yr9o8RTqH0U2ZzW3y+7XI lvH1L/9itm1qH0JGqnAxw0d65wFFWKPgGU4z5d14RiBt+gNxWC1yc9WVGXIo0tba/oyQ== X-Google-Smtp-Source: ACHHUZ4LewKI1bGCFySWrqE62ZLHx5KEb3VBip+hwqa2gh1aOI1ioNMIYIUz7W29KmuORj5hhm023g== X-Received: by 2002:a17:906:9752:b0:970:553:272c with SMTP id o18-20020a170906975200b009700553272cmr2395644ejy.27.1685025835562; Thu, 25 May 2023 07:43:55 -0700 (PDT) Received: from [10.137.0.17] (static-84-42-175-93.bb.vodafone.cz. [84.42.175.93]) by smtp.gmail.com with ESMTPSA id u8-20020a05640207c800b0050a276e7ba8sm615192edy.36.2023.05.25.07.43.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 May 2023 07:43:55 -0700 (PDT) Message-ID: <0376ae2d-570e-8837-9e93-8ada1deb2cee@enterprisedb.com> Date: Thu, 25 May 2023 16:43:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: memory leak in trigger handling (since PG12) Content-Language: en-US To: Andres Freund Cc: Tom Lane , PostgreSQL Hackers References: <222a3442-7f7d-246c-ed9b-a76209d19239@enterprisedb.com> <960113.1684859980@sss.pgh.pa.us> <20230524185559.un4dqfem3u3ktons@awork3.anarazel.de> <20230524201915.4mb7xd2cw4k6epoy@awork3.anarazel.de> From: Tomas Vondra In-Reply-To: <20230524201915.4mb7xd2cw4k6epoy@awork3.anarazel.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CLOUD-SEC-AV-Info: enterprisedb,google_mail,monitor X-CLOUD-SEC-AV-Sent: true X-Gm-Spam: 0 X-Gm-Phishy: 0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 5/24/23 22:19, Andres Freund wrote: > > ... > > Hm - stepping back a bit, why are we doing the work in ExecGetAllUpdatedCols() > over and over? Unless I am missing something, the result doesn't change > across rows. And it doesn't look that cheap to compute, leaving aside the > allocation that bms_union() does. > > It's visible in profiles, not as a top entry, but still. > > Perhaps the easiest to backpatch fix is to just avoid recomputing the value? > But perhaps it'd be just as problmeatic, because callers might modify > ExecGetAllUpdatedCols()'s return value in place... > Yes, I think that's a perfectly valid point - I was actually wondering about that too, but I was focused on fixing this in backbranches so I left this as a future optimization (assuming it can be cached). regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company