Re: Why does pgindent's README say to download typedefs.list from the buildfarm?
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter@eisentraut.org>, Robert Haas <robertmhaas@gmail.com>, Nathan Bossart <nathandbossart@gmail.com>, pgsql-hackers@postgresql.org
Date: 2024-05-17T00:45:59Z
Lists: pgsql-hackers
Attachments
- wait-event-extension-cleanup.patch (text/x-diff) patch
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
Commits
-
Sync typedefs.list with buildfarm, for real this time.
- 70353e463cd3 17.0 landed
-
Remove unused typedefs
- be5942aee7a0 17.0 landed
-
Remove enum WaitEventExtension
- 110eb4aefbad 17.0 landed
-
Add pgindent typedefs file to CVS.
- 16040575a044 9.0.0 cited