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 1w05GT-001bPO-2i for pgsql-hackers@arkaria.postgresql.org; Tue, 10 Mar 2026 22:09:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w05GS-006ILi-0r for pgsql-hackers@arkaria.postgresql.org; Tue, 10 Mar 2026 22:09:20 +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 1w05GR-006ILa-30 for pgsql-hackers@lists.postgresql.org; Tue, 10 Mar 2026 22:09:20 +0000 Received: from lahtoruutu.iki.fi ([185.185.170.37]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w05GQ-000000022Hu-0izM for pgsql-hackers@postgresql.org; Tue, 10 Mar 2026 22:09:20 +0000 Received: from [10.0.2.15] (unknown [130.41.208.2]) (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) (No client certificate requested) (Authenticated sender: hlinnaka) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 4fVp2319y0z49Q4q; Wed, 11 Mar 2026 00:09:14 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1773180556; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=59eelR8pRkRVMiDQdSzr+NRYZhlrgvKN0UmysByWuZA=; b=dRLn6jy1+JoASp9+6B1sknK1GTCiClj4LEqQfIleT3Xq6ATYFZICdysGS+eqwoEI0btsBw HL1cFiq5eeqNUl/um98wD1Fze2lECaNlhlv0SApF09ya+y8FE6iU0UYq/v434MQ/XJMleA sm3LGoLE2w5vtOQ3J6uob0vDWFpSMTTP1P4kAuxBnV9ndJ/NqPmIQ73GfnAoLE2ieIa3Oj 0/uPXq6F6xkqREP5Vnhj+fEBigUHYUVfNFiqXIKB/d4uGgW5y7wrs9NjDzk+A0PrCcNzno X0VmEWPXpEJ2KQNKRv5GnR0HACijEGwVFKLfRItIUZsxc4PvzBrq/toSzyAl+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1773180556; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=59eelR8pRkRVMiDQdSzr+NRYZhlrgvKN0UmysByWuZA=; b=Z0A5ZSVjyvqIft/LfBQH0SjVSlKSpfY56MphRwgJvx0JzocPK040M7tABHk5UOuABj8pPl /nVYZD1k9NztE1g/kikDc4VSPWAX3BkYGvddVyLjICOXkRiMqlm6xRvHGMPFbgv0WS+8FE 2uKyCWrVHgvX2b0bY5KpEF3lkVwzalq9lF/y/FOj72r4XJeyPNUKGA75c3fd+xJ4GufOlh nORFPz4hjKcQEc0YbDBojtXkzsBUjXRz+ARLPIy7rFthje1pAzcN60cZ5VyAfzJjao077o MbYJWQClc1nDqV65kOQH8hci/17y8F5izMyn3/q7jqLKWznexACsPHIUgHnHxw== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=hlinnaka smtp.mailfrom=hlinnaka@iki.fi ARC-Seal: i=1; a=rsa-sha256; d=iki.fi; s=lahtoruutu; cv=none; t=1773180556; b=Ls2FEivLv4DM5gQPY1ZmLoouIKAKFoKo5oZFbFpeTbS6WpM5z8u5WiM93+N9zUt/H7vM7Z 8nLpWQWOvVj+zNF6CadJ4WNWp+BTwjwjYx9zTe7zl0rqjLQl4six0Aicpe0JauZTTxewr+ fc6cgF1YUEMQhIGaG2Wb0v1eGms0uc3ydiXm4We/NvuECt48OSRyCIiBtHfBBc0WbYyfyl 6iCQV+IgkjnpqMC8IxxOQPfvsIZtPOEy6o3KA9DRQXCVeoXZ58v5unr6NIikPN0ty/2WwJ s8kQOoszYGUXO9k+0b9QUYlCiV6PeGyR9VhxNhq3Ah0wSDp7tHbgeUIW1S8TGw== Message-ID: Date: Wed, 11 Mar 2026 00:09:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Fix uninitialized xl_running_xacts padding To: Alexander Kuzmenkov , Andres Freund , Anthonin Bonnefoy Cc: Bertrand Drouvot , Michael Paquier , Thomas Munro , PostgreSQL Hackers References: Content-Language: en-US From: Heikki Linnakangas 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 10/03/2026 23:51, Alexander Kuzmenkov wrote: > On 16/02/2026 21:10, Andres Freund wrote: >> I don't think it makes a whole lot of sense to tackle this >> specifically for >> xl_running_xacts. Until now we just accepted that WAL insertions can >> contain >> random padding. If we don't want that, we should go around and make >> sure that >> there is no padding (or padding is initialized) for *all* WAL records, >> document that as the rule, and remove the relevant valgrind suppressions. > > That's not random, that's server memory, right? Probably not another > Heartbleed, but I'd rather initialize a few locals than find out. > > Happy to see this being worked on, these uninitialized WAL records are a > major obstacle to enabling MemorySanitizer. I ran into this again today > and this is how I found this thread. Unfortunately the MemorySanitizer > can't even use the same suppressions as Valgrind, because the > suppression architecture is different (can only remove the checks from a > given function, not all stack traces that have this function like > Valgrind does). +1 for initializing all padding in WAL records. In fact I thought that we already did that. (Except in this case, apparently) - Heikki