Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rfXEK-000l9S-Lx for pgsql-bugs@arkaria.postgresql.org; Thu, 29 Feb 2024 03:37:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rfXEH-00HBRi-Br for pgsql-bugs@arkaria.postgresql.org; Thu, 29 Feb 2024 03:37:05 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rfXEG-00HBRa-Vd for pgsql-bugs@lists.postgresql.org; Thu, 29 Feb 2024 03:37:05 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rfXEC-0021Mx-Py for pgsql-bugs@lists.postgresql.org; Thu, 29 Feb 2024 03:37:03 +0000 Received: from [172.30.0.166] (unknown [172.30.0.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: a.lepikhov@postgrespro.ru) by mail.postgrespro.ru (Postfix/587) with ESMTPSA id 5E52DE21132; Thu, 29 Feb 2024 06:36:57 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1709177818; bh=sfQLv6mQTs2JW0RKIhlqBG9dILc5H0VWKlytsa3i+uI=; h=Message-ID:Date:User-Agent:Subject:To:References:From:In-Reply-To: From; b=krk8mppV5Z1K5FhKxfwncXkjXInAVpN8O+jeNkJaUCSxmXN+66LYI+W6P0ZWKi/Iw Bj4lqh01XiBHw33EILdzIMJQw6brKlVMgmbRa6PnJemCKrdmYOq8DTJYzSR2KQcft/ GvjOUgkTplrbBo41JzadfHtLmUX4nEHUD/WZbTW+VA++hHe5JADHztDt3Tg/w/btVO mKUZW1RSYPSgNLFJQdGfSAC0CFKlQ/DwBgmrADVu/Ry3K2ewkrfJNdy1nfJ4+no+s9 VNU+qN5S4eHtBfcFp5nLGQl83jdtezLBE+nmnVNpa1HQN/MB2wvH2tFz/jRBsnO0uj PYpFKhp18wVKA== Message-ID: <7a1f5e5b-632f-4cc5-8078-b18a848e8924@postgrespro.ru> Date: Thu, 29 Feb 2024 10:36:55 +0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: BUG #18349: ERROR: invalid DSA memory alloc request size 1811939328, CONTEXT: parallel worker Content-Language: en-US To: Tomas Vondra , Alexey Ermakov , pgsql-bugs@lists.postgresql.org References: <18349-83d33dd3d0c855c3@postgresql.org> <512ef568-336e-4087-ba23-f22b006d329d@postgrespro.ru> From: Andrei Lepikhov Organization: Postgres Professional In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 21/2/2024 19:52, Tomas Vondra wrote: > Hi, > > On 2/20/24 15:05, Alexey Ermakov wrote: >> On 2024-02-16 20:40, Andrei Lepikhov wrote: >>> Interesting. It correlates with one performance issue I have been >>> trying to catch already 3 months. Could you provide some reproduction >>> of that behavior? >>> >> Yes, I'm still trying to make reproducer, it will take some time. Thanks. >> > It's a bit weird it needs 1.8GB of memory, but perhaps that's also > linked to the number of batches, somehow? I found one possible weak point in the code of PHJ: ExecParallelHashJoinSetUpBatches: pstate->batches = dsa_allocate0(hashtable->area, EstimateParallelHashJoinBatch(hashtable) * nbatch); It could explain why we have such a huge memory allocation with a size not bonded to a power of 2. Also, it makes more sense that we already have a second report [1] with the same value of DSA allocation. So, can Alexey apply a trivial patch and check whether the bug has gone? [1] https://www.postgresql.org/message-id/flat/PAYP264MB3368AF4D63704E370B204C39FF582%40PAYP264MB3368.FRAP264.PROD.OUTLOOK.COM -- regards, Andrei Lepikhov Postgres Professional