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 1vs3QJ-0036Ck-10 for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Feb 2026 18:34:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vs3QH-004qS3-2U for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Feb 2026 18:34:17 +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 1vs3QH-004qRv-1N for pgsql-hackers@lists.postgresql.org; Mon, 16 Feb 2026 18:34:17 +0000 Received: from fout-a2-smtp.messagingengine.com ([103.168.172.145]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vs3QF-0000000147T-1Xmr for pgsql-hackers@postgresql.org; Mon, 16 Feb 2026 18:34:17 +0000 Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailfout.phl.internal (Postfix) with ESMTP id 239F7EC0582; Mon, 16 Feb 2026 13:34:14 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-12.internal (MEProxy); Mon, 16 Feb 2026 13:34:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kurilemu.de; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to; s=fm2; t=1771266854; x= 1771353254; bh=xpiAuaxxVfGSaFZ+ZHe8dM1oPCtcWwg4ZCnJslG5JKk=; b=e L/ts5/JpDvjBFBqJizZ62TrO6N6GosAhEQv8C/9oI8gKJ71WRD0cfEoflwGm1imI qXpZUKJ7Yxyt61iSfnpNfcC9y41YI7EPOnKxn4jn0QVXelUiSBvTSCDxYBK5c7BR IoSCg3JEyoKkpx97+XfX+KbyJ/19SSDJnwGC5e6tjjorrx2BO9o/NxTM9sDjxj/t UqBTNiPOXSQQJXgaDzoayox2Lgu+Ut2l3bFuK/FG7wg4pcmFnh78QuSCQR8HVjXV i/PhPgVBNI0ruUqjsZmMNlTVJDgJQtZ29IHGRizBw2hhIAIlj6TPejQBfGNNYRgS rd9S7c1zWpSHL7985RDWg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1771266854; x=1771353254; bh=x piAuaxxVfGSaFZ+ZHe8dM1oPCtcWwg4ZCnJslG5JKk=; b=wPP9nSY49dRlrg3XN KWD9MTLMMCBo1Vycz+xH5ggjQidfEJvUKLWNNzhLQ0AnRQOdSIdc9HxK+cKuKT14 77x1Q1v/uU7EPfXjliOsm7sZ4J99v2vOO8e/rPAvZxA44u4a8GJ8SZI56j2zWe5y ZmQDTR/EfY+6Y23YFJVGzUweseLzuYdROOM4P4blgHtNalRLCl04SctV7C6SxzPq vhhbi1EczOJrmIfEzbN/0IM9iuENzaGIsd1souOup4neY135Lbck6WcQOg/6OoHg Ptajvl4EONcervjsBlQ6UX26GMdFSswMofHkHx9krmYxvDP90xYkWSyEnFWemQRZ o+Ghw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvudejiedtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgrrhho ucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsehkuhhrihhlvghmuhdruggvqeenucggtf frrghtthgvrhhnpeeiheehkeekleegueeifedvffegtddugeffheehfeeftdduhfdtkeef leelkeffjeenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhhvghrrhgv sehkuhhrihhlvghmuhdruggvpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmthhpoh huthdprhgtphhtthhopegrnhgurhgvshesrghnrghrrgiivghlrdguvgdprhgtphhtthho pegrmhhithdrkhgrphhilhgrudeisehgmhgrihhlrdgtohhmpdhrtghpthhtohepmhhitg hhrggvlhesphgrqhhuihgvrhdrgiihiidprhgtphhtthhopehpghhsqhhlqdhhrggtkhgv rhhssehpohhsthhgrhgvshhqlhdrohhrgh X-ME-Proxy: Feedback-ID: ie3de48e3:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 16 Feb 2026 13:34:13 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kurilemu.de; s=schmee; t=1771266852; bh=ms5WIQjMmflkMHohRWHznF9O4gNorZWESMq3XNMBouo=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=IWB+YN1lqK8cQCtKHcf5x2a8itivG/QQ4LOPFxMWRhrZiCNtNNC38J1lLV0FVcKwW sTD3TYMNNxGa/KOujeOwo2aeucCtAJ2qiNoAXJL6oc06cjT6aYPb4AmG18ffQRecmt ZtnmGp0Zr6xSNU+4E+TpA3sI82/Y5j70rWvh5+o5f114cocxAsDWEITIYv8KQpzpTT xgWb6nJaiWgfqKb6UvkzGgRgBmI3/d70wcE0PaDGj80mIT62RBjpojC1W5R5Wgguw7 1WLdSS2xwFyQhLSNTG698VZt4LVCMfgm4FZuHD83x2KNWBwuoKEW/ZNSVt8l02jX8L L6Fgi6SzP2ApQ== Received: by schmee.kurilemu.internal (Postfix, from userid 1000) id 21C087A; Mon, 16 Feb 2026 19:34:12 +0100 (CET) Date: Mon, 16 Feb 2026 19:34:12 +0100 From: Alvaro Herrera To: Andres Freund Cc: pgsql-hackers@postgresql.org, Amit Kapila , Michael Paquier Subject: Re: pgstat include expansion Message-ID: <202602161822.odmfaonidtop@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello, On 2026-Feb-16, Andres Freund wrote: > On 2026-02-16 17:18:36 +0100, Alvaro Herrera wrote: > > I don't think the removal of pg_list.h works terribly well though, as > > that is something that I would expect to be pretty much everywhere, so > > it seems somewhat pointless to try to avoid it in this file. > > Yea, I was on the fence about that one. > > It does seem pretty crappy that pg_list.h is so widely included and in turn > includes nodes/nodes.h, which then depends on the generated nodetags.h. For > one it forces an unnecessary rebuild of too much if you add a new node type, > but it also just aesthetically feels wrong. Yeah, I was unhappy about pg_list.h too on my recent header hacking, and perhaps we can improve this somehow, but I think it's a bigger effort. > > I think we should in addition remove some includes that were kept during > > recent IWYU hacking "for backwards compatibility", and instead include > > them explicitly wherever they are needed. The attached does that. > > FWIW, the "for backwards compatibility" includes are from prep work towards > shared memory stats. Before that all the stuff in backend_status.h, > backend_progress.h and wait_event.h was in pgstat.h, which was quite > unwieldy. Ah, okay. > The creation of those headers would have broken a lot of extensions if > we had not provided those backward compat includes from pgstat.h. Right ... TBH the real issue for me is that wait_event.h includes the generated file wait_event_types.h (same complaint you had above), but I decided that if I was wielding a weapon against pgstat.h, it could as well be a shotgun. I guess I would be satisfied if we remove wait_events.h from pgstat.h, and that probably won't break as many extensions and won't have as much of a fallout. Although TB further H, I don't really see it as terribly bad if we break extensions with this kind of work, since the fix on their side is fairly easy, noninvasive, and doesn't have to be done with any urgency. > FWIW, your patch that you sent subsequently doesn't seem to apply cleanly for > me? I think it's perhaps based on an older tree, it doesn't know about the > conflict.h include yet... And it fails to build e.g. due to miscadmin.h > defines around BackendType not being indirectly included in pgstat.h anymore, > but there are many other failures... Yeah, I just wrote it on (almost) clean master, but feel free to push your changes whenever, and I'll rebase on top of that. I suspect the failures just mean that the implicit header inclusions are worse than they appear at first. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/