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?