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 1vrt3D-00BEA2-3C for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Feb 2026 07:29:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vrt3B-0048Xe-1g for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Feb 2026 07:29:45 +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.96) (envelope-from ) id 1vrt3B-0048XV-0h for pgsql-hackers@lists.postgresql.org; Mon, 16 Feb 2026 07:29:45 +0000 Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vrt38-00000000qhk-1hZf for pgsql-hackers@postgresql.org; Mon, 16 Feb 2026 07:29:44 +0000 Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-43626796202so2595541f8f.3 for ; Sun, 15 Feb 2026 23:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771226981; x=1771831781; darn=postgresql.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=+rvxlhSnR+tdL1G7IS6amlBehSK9yjVn68yw/rnTHsM=; b=MV+p8GfbXa/ma/b+pwKba+8EoMOjenS6jwxrNiJCPL86715mtRtTjQa72B9A+od8A7 yRjbT6QNOn7la39GI/iLjQPkugDlXR0IXf4cBCwS/Seq36V+OToKXdlmg2ex5WlMXIqQ iXYAhKRf7C3GrV/fJxe9JoHLgNcrbWdJGcr64rcrCAvELCqKM7imRsUJ/Yp1Dj7Ech1O Mnuzny1wNtfk1F3EWbGt/f7JuyMFwBvLhDfj9C4oWuMYXiTzyBMcVbUmmB3OrupVqDVS HuHiVflleIUKojSlMDlnEmCIpxjUA896F/FkKAusd/N2bsk7B8NNuSkoG69Ou0bwYY2f GDpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771226981; x=1771831781; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+rvxlhSnR+tdL1G7IS6amlBehSK9yjVn68yw/rnTHsM=; b=UjdKmf4kN3F6CU2T0+zo/37EZhaS+vWuJpd/qhgQR/Hp2hRJB9/lrEDwBjOSFYMNu+ D9QtbUicjTvQwq6BtbmedRU5VpTCAlw8qFokgOSjQQB4IJkbxaZXt+C7x3PkzMOfZhQz 2I/bqwhOBhVcoBVOZdda22Z3dzvAgkicT0Thrh2hklasXPwQnKyNPx46Ix44jzcMs4Tf yEP3EqAsi1GyOkAI0hWq1TonLOE3Vn3JEo2Hos/7WvYmAFErJ3K8MDJelePZhOg0uWGk PXnK2SnfqfUD4KQlDWBlQsl6ZQLafzgSxjuYbSbEms/Ua/bdxwLFy9neHbnf+HK6ZGEJ Q3Lw== X-Forwarded-Encrypted: i=1; AJvYcCWNwsh4nnsLzNpPN3Vvnc/9P8zPSYSCU+3r0yXtH3//h12kk+taFcyaKOkyCKsb95UKGudKqEmrG3AP+9LK@postgresql.org X-Gm-Message-State: AOJu0Ywq0Wp4UWn/5zov2mMrrPCbTXyKVV67IG9doTSnizDGdZ+WOPaT yNNt61z5illIgB/f6WpXURTnJ4kTjdvB0KmQbTIagSqGOj50mgmoJ0eL X-Gm-Gg: AZuq6aKG/2eDHttV5nndvlZSgLnGIydBNOtUGbd3p1Mv+AI888I1NWOWztK5n1x4wrE j4FvwdgQ/pk/WY0Cl0NdPScC6LzWcY8DUgJ5bsKMDiAgkxxNkrhEYm90hDm39b+1w1RxxVxTpjf zGEjIEA8/iAOIqbUzVqZGC8cCWnrvxVF9V/gm4aRIs5XjQbhvQgC+dcQ8BkShq8NTa+B3zZhsB0 KgsZdPYIg8mw5B2+qAor3Bgupiv3HkTpyhKCJeYVY5L6FVd8/NqZP4nGvjj6TIz1qBgLMRFsP+U pYT7q+4jXSw+1qOMdNVRbAstSU9uP7J1cpnCucvSH0GwpubGBAxTWqtC0WpC9NPoa4RxES8A3yD Agy3DbnHMFsLCVUhlQszNYf+4h3vdxkY84EAlBfdg+aH1L8sHB1g07jqfQghfJEu8SY6ea+ba7L AaEb4YwyYm7pSQTsQExAN4RqxG5Ws89tITMADJLJi38HEhd3qSRYtlt5/8EqQE99dmKgV0ypkDx 6ERDgsHNNh7NUC7w07I3XsBjISOrVT9kan3GuPvlkIcQMvYG4xR3M6p6u0Xt2Ad/L0L X-Received: by 2002:a05:6000:240a:b0:435:db6e:e3b2 with SMTP id ffacd0b85a97d-437978eb052mr18475935f8f.27.1771226980419; Sun, 15 Feb 2026 23:29:40 -0800 (PST) Received: from ip-10-97-1-34.eu-west-3.compute.internal (ec2-15-237-197-144.eu-west-3.compute.amazonaws.com. [15.237.197.144]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43796a6a5f0sm24590520f8f.11.2026.02.15.23.29.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Feb 2026 23:29:40 -0800 (PST) Date: Mon, 16 Feb 2026 07:29:38 +0000 From: Bertrand Drouvot To: Michael Paquier Cc: Thomas Munro , Anthonin Bonnefoy , PostgreSQL Hackers Subject: Re: Fix uninitialized xl_running_xacts padding Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On Mon, Feb 16, 2026 at 10:10:58AM +0900, Michael Paquier wrote: > On Mon, Feb 16, 2026 at 01:17:56PM +1300, Thomas Munro wrote: > > Nitpick: the so-called universal zero initialiser syntax (var = {0}) > > is a nicer way to do this and generally preferred in new code AFAIK. > > My memory on the matter may be fuzzy, of course, but the initializer > does not guarantee that the padding bytes are initialized to zero > because the padding bytes are not associated to a member in the > structure. A memset(0), however, makes sure that the padding bytes > are full of zeros by taking into account the full size of the > structure. That's also what I recall, and what we followed in [1]. > > But in this case, it seems we don't actually worry about initialising > > WAL padding bytes in general. valgrind.supp has an entry to prevent > > warnings about it. Should we? > > True about the initialization part, mostly I guess, still we tend to > worry about eliminating padding because these are wasted bytes in the > WAL records. For example, xlhp_freeze_plans has two bytes of padding, > that we eliminate while inserting its record by splitting the > FLEXIBLE_ARRAY_MEMBER part. But in the case of this thread it's in the middle of the struct, so I'm not sure the "wasted" bytes would be elminated, would it? Regards, [1]: https://postgr.es/m/CAGECzQS37h0twutb=kkS6v0rSnQ0vWxhVncqVNYoOTsv6gOmcw@mail.gmail.com -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com