Re: Support to define custom wait events for extensions
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tristan Partin <tristan@neon.tech>
Cc: Masahiro Ikeda <ikedamsh@oss.nttdata.com>, pgsql-hackers@lists.postgresql.org
Date: 2023-07-11T23:29:42Z
Lists: pgsql-hackers
On Tue, Jul 11, 2023 at 12:39:52PM -0500, Tristan Partin wrote: > Given the context of our last conversation, I assume this code was > copied from somewhere else. Since this is new code, I think it would > make more sense if newalloc was a uint16 or size_t. This style comes from LWLockRegisterTranche() in lwlock.c. Do you think that it would be more adapted to change that to pg_nextpower2_size_t() with a Size? We could do that for the existing code on HEAD as an improvement. > From what I understand, Neon differs from upstream in some way related > to this patch. I am trying to ascertain how that is. I hope to provide > more feedback when I learn more about it. Hmm, okay, that would nice to hear about to make sure that the approach taken on this thread is able to cover what you are looking for. So you mean that Neon has been using something similar to register wait events in the backend? Last time I looked at the Neon repo, I did not get the impression that there was a custom patch for Postgres in this area. All the in-core code paths using WAIT_EVENT_EXTENSION would gain from the APIs added here, FWIW. -- Michael
Commits
-
Change custom wait events to use dynamic shared hash tables
- af720b4c50a1 17.0 landed
-
Support custom wait events for wait event type "Extension"
- c9af05465307 17.0 landed
-
Add WAIT_EVENT_{CLASS,ID}_MASK in wait_event.c
- 7395a90db87b 17.0 landed
-
worker_spi: Switch to TAP tests
- 320c311fda91 17.0 cited
-
Simplify some conditions related to [LW]Lock in generate-wait_event_types.pl
- c17164aec88c 17.0 landed