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.96) (envelope-from ) id 1vvelC-00CK6N-0r for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Feb 2026 17:02:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vvelA-00EOy4-0x for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Feb 2026 17:02:44 +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.96) (envelope-from ) id 1vvel9-00EOxp-2i for pgsql-hackers@lists.postgresql.org; Thu, 26 Feb 2026 17:02:44 +0000 Received: from mail.postgrespro.ru ([93.174.132.70]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vvel5-00000001QSb-49OD for pgsql-hackers@lists.postgresql.org; Thu, 26 Feb 2026 17:02:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1772125359; bh=y3r41atOGwhbNlqv2UAyvd1aphlyUHvZxeoKamnzIQ4=; h=Message-ID:Date:User-Agent:Subject:To:Cc:References:From: In-Reply-To:From; b=Hc2evRhzTUJKGmLuCJn0N/0FfTqZE95GYoIMI9MHUpxqujkmZAf4glctg/WLePFIk rpr1PW6+gtY3cwLWENhP20MO0c6rjrTF+tKrHln7gKov6pW6Jr3Pc1pJwpRAqiIfJd dxDh07anbi8dTZriDrVL3HEZOKOHt0ZSRnWu4eAqyPl/UkUZ3c5qSyvR5KwstKk5p9 mua3ecSswYcdSpk1pwGMgu6DDKM0tbNSodLPzjtFx9qPGrdMQknbjVW1hQmd936VHn bZW66ejr4RKk3d5TZkjsE+EYhNKBOKEFJw4DIYOjxHE5W32YmiaD6j9zzyrB7LGDKj 3yORZQP3IuGGg== Received: from [192.168.3.107] (broadband-5-228-113-160.ip.moscow.rt.ru [5.228.113.160]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: y.sokolov@postgrespro.ru) by mail.postgrespro.ru (Postfix/465) with ESMTPSA id 236F760B05; Thu, 26 Feb 2026 20:02:39 +0300 (MSK) Message-ID: Date: Thu, 26 Feb 2026 20:02:38 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Fix bug in multixact Oldest*MXactId initialization and access To: Sami Imseih Cc: "pgsql-hackers@lists.postgresql.org" , Heikki Linnakangas , Andres Freund , Chao Li References: <7acc94b0-ea82-4657-b1b0-77842cb7a60c@postgrespro.ru> <93F0BD0A-0B8B-4592-9D4B-53F405A86F6A@gmail.com> Content-Language: en-US From: Yura Sokolov In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-KSMG-AntiPhishing: NotDetected X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 2.1.0.7854, bases: 2026/02/26 16:13:00 #28227779 X-KSMG-AntiVirus-Status: NotDetected, skipped X-KSMG-LinksScanning: not scanned, disabled by settings X-KSMG-Message-Action: skipped X-KSMG-Rule-ID: 1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 26.02.2026 19:34, Sami Imseih пишет: >> But I still use inline procs for access to the arrays. Asserts cost nothing >> in release build. And new version of functions doesn't branch. > > Asserts may have minimal impact for most builds, but my concern is > this is all unnecessary complexity. I mean if we guarantee that the > arrays are initialized correctly, maybe we can have an assert at > init time, why would we need asserts at run time? They are future proof. If there had been assertions from the beginning, there would not have been a breaking change. The tests would have failed. (Sorry, I've used Google Translate to write this sentence). When you write assert, you protect yourself from shooting your leg far in the future. Believe me. -- regards Yura Sokolov aka funny-falcon