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-gmo5ghojwtyrvak5zgovtrce...@mail.gmail.com explored, (1) would be plenty safe. Should anything change here, or not?
