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 1vveCj-00BqjV-2X for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Feb 2026 16:27:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vveCi-00EDsC-1b for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Feb 2026 16:27:08 +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 1vveCi-00EDrw-0d for pgsql-hackers@lists.postgresql.org; Thu, 26 Feb 2026 16:27:08 +0000 Received: from fout-a8-smtp.messagingengine.com ([103.168.172.151]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vveCf-00000001KN7-0kcn for pgsql-hackers@postgresql.org; Thu, 26 Feb 2026 16:27:07 +0000 Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfout.phl.internal (Postfix) with ESMTP id B41A2EC054E; Thu, 26 Feb 2026 11:27:05 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Thu, 26 Feb 2026 11:27:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1772123225; x=1772209625; bh=XIVKI11/sx /vuLdhGJPbkd2Xj3qoMvLxOvfFahEIZw0=; b=ZqNWfdZEWcamq89zHgTXOGmTLh lfZEFa50QgHM0MbrEnhaDlF3d0Oph/WVE/A21rBks1LNGm1NV1+9tyJsZtrhZLBe EkQ+UzOA7YICP/+Gs7pWItYZdrv/GesNdO8uhbNg0uYDvLFz4v8r7ztHdt7Pfl9I JbbzqZ26YkHywSJQvX6TwSj114k2MFkBN7IEQi5XP9YUvNqhhHUrISmurRYYLui+ eqad121UgNszAsKV5K1pzRpVUMtAA+eDiPq6HpnfKARrAOSsUn8f+zC13+qb7rdg smUtNIR5lUt5X4qb0QFzuQU4gNya5aFQhPrHwCc8x4vdP9xzrHERHzaOyOPg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1772123225; x=1772209625; bh=XIVKI11/sx/vuLdhGJPbkd2Xj3qoMvLxOvf FahEIZw0=; b=ZdXUubSgqsnxznSC83eBC+WkfxaWChQSzG1iuSswSDeGMvoHLzm w98CnPbIPBYGUTL5ssQtKjDqqlzc5vaP/CFGLWy0ac7J43EjHe7L+OFUdJUfLWgu FXnBYfiopgHElhQJYkoEPJKbHKmm/DO4SCqtznnTk5Uo11Uh1R+4r3A4elvYy/jW NY4gZ2dw7qFHa1wJcT+OMAPmGKaGQCqyYyzO/iy1Ax4IysKW4SxZjg7Itxra7C5C lCg9rwPDkpaXSdc2I06gXgXUD54r0hnGe0+aGj9XKHl94Qh+gQUpUsEdVdZYBJX+ ZlPpxPywDSkiHedDvUP77d//jDxCR3SDo+Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvgeeihedvucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesthdtsfdttddtvdenucfhrhhomheptehnughrvghs ucfhrhgvuhhnugcuoegrnhgurhgvshesrghnrghrrgiivghlrdguvgeqnecuggftrfgrth htvghrnhepfeffgfelvdffgedtveelgfdtgefghfdvkefggeetieevjeekteduleevjefh ueegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hnughrvghssegrnhgrrhgriigvlhdruggvpdhnsggprhgtphhtthhopeehpdhmohguvgep shhmthhpohhuthdprhgtphhtthhopegrmhhithdrkhgrphhilhgrudeisehgmhgrihhlrd gtohhmpdhrtghpthhtohephhhlihhnnhgrkhgrsehikhhirdhfihdprhgtphhtthhopegr lhhvhhgvrhhrvgeskhhurhhilhgvmhhurdguvgdprhgtphhtthhopehmihgthhgrvghlse hprghquhhivghrrdighiiipdhrtghpthhtohepphhgshhqlhdqhhgrtghkvghrshesphho shhtghhrvghsqhhlrdhorhhg X-ME-Proxy: Feedback-ID: id4a34324:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 26 Feb 2026 11:27:05 -0500 (EST) Date: Thu, 26 Feb 2026 11:27:04 -0500 From: Andres Freund To: Alvaro Herrera Cc: Heikki Linnakangas , pgsql-hackers@postgresql.org, Amit Kapila , Michael Paquier Subject: Re: pgstat include expansion Message-ID: References: <55orfweo3sys7g5vstb3ufv7es2fxyi2tj7rrfwn4okasay5hw@eiktf4jpwnnz> <202602261523.yu3fs2tpzszl@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202602261523.yu3fs2tpzszl@alvherre.pgsql> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 2026-02-26 16:59:12 +0100, Alvaro Herrera wrote: > On 2026-Feb-26, Andres Freund wrote: > > On 2026-02-26 14:52:10 +0100, Alvaro Herrera wrote: > > > This one removes wait_event.h from pgstat.h. The only difference from > > > the previous one, aside from the fact that I had to add pgstat.h to a > > > few more .c files, is that xlogreader.c needs to include it inside the > > > #ifndef FRONTEND; otherwise, "ninja -t missingdeps" complain about the > > > file being used in pg_rewind and pg_waldump (seen in CI). > > > > I'm somewhat worried about the amount of breakage this will cause in > > extensions. Many extensions use something like > > WaitLatch(wait_event_info = WAIT_EVENT_EXTENSION) > > and many of them won't have included wait_event.h. > > Yeah, I considered that, and instead of breaking these, to include > wait_event.h in latch.h. This sounds a very reasonable thing to do. > But then I searched for other headers that have a wait_event_info > parameter in one of their functions, and if we force those to also > acquire wait_event.h, then the pollution is much worse than if we just > leave it in pgstat.h. (condition_variable.h, fd.h, proc.h, barrier.h). > > The problem is that some of those headers are in turn being included by > others; most notably condition_variable.h is used in execnodes.h and > others, and that makes a huge mess. (And it can't be removed.) > > However, maybe we can just not be so principled about it, add it to > latch.h, and then we don't break the whole world. I'll try that. FWIW, regardless of what we choose here (i.e. whether and where to "unnecessarily" include wait_event.h), I'd be in favor of fixing all the fallout in our source tree, just for cleanliness' sake. It's also presumably the part of the patch that would be the most pain to keep updated. I'm not sure that including in latch.h really would an improvement though - that's included in proc.h and libpq.h, which both are fairly widely included [1]. FWIW, I'm a lot less concerned with extension users of condition_variable.h, fd.h, proc.h, barrier.h breaking due to removal of an implicit include, I don't think they are remotely as widely used. Greetings, Andres Freund [1] Although at least the include in libpq.h seems like it could trivially be replaced by a forward declaration. There's only three .c files that need to be fixed for that...