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 1rGCtR-00EDxR-Rn for pgsql-hackers@arkaria.postgresql.org; Thu, 21 Dec 2023 06:50:54 +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 1rGCtQ-004VdO-HP for pgsql-hackers@arkaria.postgresql.org; Thu, 21 Dec 2023 06:50:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rGCtQ-004VdF-3y for pgsql-hackers@lists.postgresql.org; Thu, 21 Dec 2023 06:50:52 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rGCtL-00D86l-Jm for pgsql-hackers@postgresql.org; Thu, 21 Dec 2023 06:50:49 +0000 Received: from [20.10.0.80] (unknown [5.182.58.202]) (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 3F0ACE21014; Thu, 21 Dec 2023 09:50:45 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1703141445; bh=2rltutLUENuQTCoevMCm5AlFVJewRnMLukePpmMNwmQ=; h=Message-ID:Date:User-Agent:Subject:To:Cc:References:From: In-Reply-To:From; b=td8151Blhhe8GqFsaaCTXO6LjSIpEr6yoAOf2oTndIJXXtNNwvT3bb7/QpBirAEgA huXpC+3tFVovo0jboHtzSV2zV5IJWr4nIjmVVrvN/LZEoKTtJH9Fv3CgWALhSWhVPG go0X3OjQDRx6ipuRmJlsQ1UY6yK/XGkcbAdSFN3QPtElqFruUNyKKRaMRgK7jdIQGW 7jzR1H5A5UiTqanf49jRJp4/V8oNI7LGs35SSENGsisdvPPEzarlIyB71WgUIXYSEv 4HzZVwTm5U28WzjbEp8Bca3sF81W3dTwQYAIhdyyASkrbNUUaIJfjhVqJZqlHCDncK aEs1HjNS2afgg== Message-ID: <8d5b2883-8f55-413c-9548-097748709fc4@postgrespro.ru> Date: Thu, 21 Dec 2023 08:50:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: introduce dynamic shared memory registry Content-Language: en-US To: Nathan Bossart Cc: Michael Paquier , Robert Haas , pgsql-hackers@postgresql.org References: <20231205034647.GA2705267@nathanxps13> <3dcea2e9-c46d-4e4f-8371-9526d1aebc83@postgrespro.ru> <20231219161444.GD831499@nathanxps13> <80cbdd55-8a9d-4472-b360-893309e1f6ef@postgrespro.ru> <20231220153342.GA833819@nathanxps13> From: Andrei Lepikhov Organization: Postgres Professional In-Reply-To: <20231220153342.GA833819@nathanxps13> 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 20/12/2023 17:33, Nathan Bossart wrote: > On Wed, Dec 20, 2023 at 11:02:58AM +0200, Andrei Lepikhov wrote: >> In that case, maybe change the test case to make it closer to real-life >> usage - with locks and concurrent access (See attachment)? > > I'm not following why we should make this test case more complicated. It > is only intended to test the DSM registry machinery, and setting/retrieving > an atomic variable seems like a realistic use-case to me. I could provide you at least two reasons here: 1. A More complicated example would be a tutorial on using the feature correctly. It will reduce the number of questions in mailing lists. 2. Looking into existing extensions, I see that the most common case of using a shared memory segment is maintaining some hash table or state structure that needs at least one lock. Try to rewrite the pg_prewarm according to this new feature, and you will realize how difficult it is. -- regards, Andrei Lepikhov Postgres Professional