On Thu, May 16, 2024 at 10:45:18AM -0400, Tom Lane wrote:
> I am also quite confused by that. It seems to be kind of an enum
> that is supposed to be extended at runtime, meaning that neither
> of the existing enum member values ought to be used as such, although
> either autoprewarm.c didn't get the memo or I misunderstand the
> intended usage. NUM_BUILTIN_WAIT_EVENT_EXTENSION is possibly the
> most bizarre idea I've ever seen: what would a "built-in extension"
> event be exactly? I think the enum should be nuked altogether, but
> it's a bit late to be redesigning that for v17 perhaps.
You're right, WaitEventExtension is better gone. The only thing that
matters is that we want to start computing the IDs assigned to the
custom wait events for extensions with a number higher than the
existing WAIT_EXTENSION to avoid interferences in pg_stat_activity, so
this could be cleaned up as the attached.
The reason why autoprewarm.c does not have a custom wait event
assigned is that it does not make sense there: this would not show up
in pg_stat_activity. I think that we should just switch back to
PG_WAIT_EXTENSION there and call it a day.
I can still clean up that in time for beta1, as in today's time. But
that can wait, as well. Thoughts?
--
Michael