On Thu, Aug 10, 2023 at 08:09:34PM +0200, Drouvot, Bertrand wrote:
> Agree that's worth it given the fact that iterating one more time is not that
> costly here.
I have reviewed v4, and finished by putting my hands on it to see what
I could do.
+ printf $wc "\telement = (wait_event_element *) palloc(sizeof(wait_event_element));\n";
+
+ printf $wc "\telement->wait_event_type = \"%s\";\n", $last;
+ printf $wc "\telement->wait_event_name = \"%s\";\n", $wev->[1];
+ printf $wc "\telement->wait_event_description = \"%s\";\n\n", $new_desc;
+
+ printf $wc "\twait_event = lappend(wait_event, element);\n\n";
+ }
This is simpler than the previous versions, still I am not much a fan
of implying the use of a list and these pallocs. There are two things
that we could do:
- Hide that behind a macro defined in wait_event_funcs.c.
- Feed the data generated here into a static structure, like:
+static const struct
+{
+ const char *type;
+ const char *name;
+ const char *description;
+}
After experimenting with both, I've found the latter a tad cleaner, so
the attached version does that.
+ <structfield>description</structfield> <type>texte</type>
This one was difficult to see..
I am not sure that "pg_wait_event" is a good idea for the name if the
new view. How about "pg_wait_events" instead, in plural form? There
is more than one wait event listed.
One log entry in Solution.pm has missed the addition of a reference to
wait_event_funcs_data.c.
And.. src/backend/Makefile missed two updates for maintainer-clean & co,
no?
One thing that the patch is still missing is the handling of custom
wait events for extensions. So this still requires more code. I was
thinking about listed these events as:
- Type: "Extension"
- Name: What a module has registered.
- Description: "Custom wait event \"%Name%\" defined by extension".
For now I am attaching a v5.
--
Michael