From: Noah Misch <noah@leadboat.com>
To: Drouvot, Bertrand <bertranddrouvot.pg@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Autogenerate some wait events code and documentation
Date: Sun, 17 Mar 2024 11:31:14 -0700
Message-ID: <20240317183114.16@rfd.leadboat.com> (raw)
In-Reply-To: <ZKTN//NfDeP1egLW@paquier.xyz>
References: <106e8d0a-0820-687a-7da5-3143e1f5b05b@gmail.com>
<ZGM1U5D5EuBUbasi@paquier.xyz>
<976f4eb1-cbc0-9616-ec26-ebb4a252315c@gmail.com>
<ZGSM8oOpXsXrXy/v@paquier.xyz>
<69588eaf-02d7-95a8-0da4-3e120de16a59@gmail.com>
<ZGWrTn//v+WAqMpN@paquier.xyz>
<ZKJxZrnFTxoCx8a5@paquier.xyz>
<ZKJ0tzXSH1LyqI9V@paquier.xyz>
<0b3cdac7-f078-61a6-76e0-99db7aae78ce@gmail.com>
<ZKTN//NfDeP1egLW@paquier.xyz>
On Wed, Jul 05, 2023 at 10:57:19AM +0900, Michael Paquier wrote:
> I have applied it.
I like the new developer experience of adding a wait event. After release of
v17, how should we approach back-patching an event, like was done in commits
8fa4a1a 1396b5c 78c0f85? Each of those commits put the new event at the end
of its released-branch wait_event.h enum. In v17,
generate-wait_event_types.pl sorts events to position them. Adding an event
will renumber others, which can make an extension report the wrong event until
recompiled. Extensions citus, pg_bulkload, and vector refer to static events.
If a back-patch added WAIT_EVENT_MESSAGE_QUEUE_SOMETHING_NEW, an old-build
pg_bulkload report of WAIT_EVENT_PARALLEL_CREATE_INDEX_SCAN would show up in
pg_stat_activity as WAIT_EVENT_PARALLEL_BITMAP_SCAN. (WAIT_EVENT_EXTENSION is
not part of a generated enum, fortunately.) Some options:
1. Don't back-patch wait events to v17+. Use the closest existing event.
2. Let wait_event_names.txt back-patches control the enum order. For example,
a line could have an annotation that controls its position relative to the
auto-sorted lines. For another example, the generator could stop sorting.
3. Accept the renumbering, because the consequence isn't that horrible.
Option (3) is worse than (1), but I don't have a recommendation between (1)
and (2). I tend to like (1), a concern being the ease of accidental
violations. If we had the ABI compliance checking that
https://postgr.es/m/flat/CAH2-Wzk7tvgLXzOZ8a22aF-gmO5gHojWTYRvAk5ZgOvTrcEQeg@mail.gmail.com
explored, (1) would be plenty safe. Should anything change here, or not?
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: noah@leadboat.com, bertranddrouvot.pg@gmail.com, michael@paquier.xyz, pgsql-hackers@lists.postgresql.org
Subject: Re: Autogenerate some wait events code and documentation
In-Reply-To: <20240317183114.16@rfd.leadboat.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox