Re: pgstat include expansion

From: Alvaro Herrera <alvherre(at)kurilemu(dot)de>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>
Subject: Re: pgstat include expansion
Date: 2026-03-05 15:08:27
Message-ID: 202602280858.ypc5z67ajlf4@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2026-Feb-27, Alvaro Herrera wrote:

> Here's one more patch. I noticed that the call actually uses
> PG_WAIT_EXTENSION, which is in storage/wait_classes.h. Including that
> seems a bit narrow-minded even if it's just for backwards compatibility,
> so I decided to do wait_event_types.h instead. This is still a bit
> better than the whole wait_event.h IMO. And also now it's IWYU: export
> rather than IWYU: keep, which seems sensible.

Actually, I think this is not a great idea, because if we do that, then
wait_event_types.h (the generated header) is, overall, included in more
files than before, so it'd be a net loss. But if we include
wait_classes.h in latch.h instead, then that aspect is definitely much
better, and I can't find anything that gets worse. (Any code that wants
to use other wait events can include wait_event_types.h or wait_event.h
themselves). So I propose to close this with the attached patch.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"The important things in the world are problems with society that we don't
understand at all. The machines will become more complicated but they won't
be more complicated than the societies that run them." (Freeman Dyson)

Attachment Content-Type Size
v2-0001-Don-t-include-wait_event.h-in-pgstat.h.patch text/x-diff 37.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Matheus Alcantara 2026-03-05 15:12:14 Re: pg_upgrade fails when extension_control_path is used
Previous Message Fujii Masao 2026-03-05 15:04:00 Re: Improve checks for GUC recovery_target_xid