The current design behind the automatic generation of the C code and
documentation related to wait events introduced in fa88928470 does not
offer a way to attach new wait events without breaking ABI
compatibility, as all the events are forcibly reordered for each section
in the input file wait_event_names.txt. Adding new wait events to
stable branches is something that has happened in the past, 0b6517a3b7
being a recent example of that with VERSION_FILE_SYNC, so we need a way
to generate any C code for wait events while maintaining compatibility
on stable branches already released.
This commit solves this issue by adding a new region called
"ABI_compatibility" (keyword could be updated to something else if
someone had a better idea) to each section of wait_event_names.txt, so
as one can add new wait events to stable branches in
wait_event_names.txt while keeping the code ABI-compatible.
"ABI_compatibility" has no impact on the documentation generated: all
the wait events of one section are still alphabetically ordered. LWLock
and Lock sections generate their C code elsewhere, so they do not need
an "ABI_compatibility" region.
For example, let's imagine a wait_event_names.txt like that:
Section: ClassName - Foo
FOO_1 "Waiting in Foo 1"
FOO_2 "Waiting in Foo 2"
ABI_compatibility:
NEW_FOO_1 "Waiting in New Foo 1"
NEW_BAR_1 "Waiting in New Bar 1"
This results in the following enum, where the events in the ABI region
are listed last with the same ordering as in wait_event_names.txt:
typedef enum
{
WAIT_EVENT_FOO_1,
WAIT_EVENT_FOO_2,
WAIT_EVENT_NEW_FOO_1,
WAIT_EVENT_NEW_BAR_1
} WaitEventFoo;
New wait events added in stable branches should be added at the end of
each ABI_compatibility region, and ABI_compatibility should remain empty
on HEAD and unreleased stable branches.
This design has been suggested by Noah Misch and me.
Reported-by: Noah Misch
Author: Bertrand Drouvot
Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/20240317183114.16@rfd.leadboat.com
f98dbdeb51