Thread: Multiple Wait Events for extensions
Hello, I'm playing with adding into my pg_stat_statements extension a wait event for pgss time duration (pgss_store) Adding pgstat_report_wait_start(PG_WAIT_EXTENSION) gives wait type = "Extension" / event name "Extension" and that's perfect. Now I would like to add a second wait event (for exemple a Planner information based on planner_hook) Yes I know it's not a "wait", but that's not even possible because there is only one event type and one event name available for all extensions ... Could this be changed to offer an extension the ability to log multiple events and many extensions to work together ? What about a pgstat_report_extension_wait_start(i) function displaying Wait type = "Extension name" and a predifined event numbers (i in the range 1 to 10) as event name ? I'm not able to write it, but I'm ready to test it deeply ;o) Regards PAscal -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
On Mon, Oct 22, 2018 at 10:28:14AM -0700, legrand legrand wrote: > Could this be changed to offer an extension the ability to log multiple > events and many extensions to work together? I recall that this issue has been discussed when adding new wait events, and we discarded it for simplicity as that's not trivial. A new facility could be implemented to add custom wait events. This exists for light-weight locks for example. I am not sure in which shape this could actually happen though ;) -- Michael
Attachment
Would a hard coded solution as described here after possible for mid-term ?
note:
actual result from
pgstat_report_wait_star(PG_WAIT_EXTENSION);
is preserved.
Regards
PAscal
pgstat.h
/* ----------
* Wait Events - Extension
*
* Use this category when an extension is waiting.
* ----------
*/
typedef enum
{
WAIT_EVENT_EXTENSION_EXT = PG_WAIT_EXTENSION,
WAIT_EVENT_EXTENSION_1,
WAIT_EVENT_EXTENSION_2,
WAIT_EVENT_EXTENSION_3,
WAIT_EVENT_EXTENSION_4,
WAIT_EVENT_EXTENSION_5,
WAIT_EVENT_EXTENSION_6,
WAIT_EVENT_EXTENSION_7,
WAIT_EVENT_EXTENSION_8,
WAIT_EVENT_EXTENSION_9,
} WaitEventExtension;
pgstat.c
...
case PG_WAIT_EXTENSION:
{
WaitEventExtension w = (WaitEventExtension) wait_event_info;
event_name = pgstat_get_wait_extension(w);
break;
}
...
/* ----------
* pgstat_get_wait_extension() -
*
* Convert WaitEventExtension to string.
* ----------
*/
static const char *
pgstat_get_wait_extension(WaitEventExtension w)
{
const char *event_name = "unknown wait event";
switch (w)
{
case WAIT_EVENT_EXTENSION_EXT:
event_name = "Extension";
break;
case WAIT_EVENT_EXTENSION_1:
event_name = "Extension_1";
break;
case WAIT_EVENT_EXTENSION_2:
event_name = "Extension_2";
break;
case WAIT_EVENT_EXTENSION_3:
event_name = "Extension_3";
break;
case WAIT_EVENT_EXTENSION_4:
event_name = "Extension_4";
break;
case WAIT_EVENT_EXTENSION_5:
event_name = "Extension_5";
break;
case WAIT_EVENT_EXTENSION_6:
event_name = "Extension_6";
break;
case WAIT_EVENT_EXTENSION_7:
event_name = "Extension_7";
break;
case WAIT_EVENT_EXTENSION_8:
event_name = "Extension_8";
break;
case WAIT_EVENT_EXTENSION_9:
event_name = "Extension_9";
break;
/* no default case, so that compiler will warn */
}
return event_name;
}
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
On Wed, Oct 24, 2018 at 11:18:13AM -0700, legrand legrand wrote: > Would a hard coded solution as described here after possible for > mid-term? I don't think I would commit that as we would want a better solution with custom names, but patching Postgres to do so with a custom build would be easy enough.. -- Michael
Attachment
Michael Paquier-2 wrote > On Wed, Oct 24, 2018 at 11:18:13AM -0700, legrand legrand wrote: >> Would a hard coded solution as described here after possible for >> mid-term? > > I don't think I would commit that as we would want a better solution > with custom names, but patching Postgres to do so with a custom build > would be easy enough.. -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
Michael Paquier-2 wrote > On Wed, Oct 24, 2018 at 11:18:13AM -0700, legrand legrand wrote: >> Would a hard coded solution as described here after possible for >> mid-term? > > I don't think I would commit that as we would want a better solution > with custom names, but patching Postgres to do so with a custom build > would be easy enough.. I can't deploy a custom build in my context, and will reuse existing spare events like - 0x050E0000U "Activity"-"unknown wait event" - 0x0B010000U "???"-"unknown wait event" - ... An other idea that may be called a "better wait event error handling" would have be to display: "???-xx" unknown event type (xx being the associated number) in pgstat_get_wait_event_type() "unknown wait event - yy" unknown event name (yy being the associated number) in pgstat_get_wait_event() giving an extended range of spare events ;o) Regards PAscal -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
On Sun, Oct 28, 2018 at 10:12:48AM -0700, legrand legrand wrote: > An other idea that may be called a "better wait event error handling" > would have be to display: > > "???-xx" unknown event type (xx being the associated number) > in pgstat_get_wait_event_type() > > "unknown wait event - yy" unknown event name (yy being the associated > number) > in pgstat_get_wait_event() > > giving an extended range of spare events ;o) Those look like half-baked workarounds in my opinion. What we may want to finish with is the possibility to register a new event with a custom string bundled so as an extension loaded via shared_preload_libraries could call it. That's not a small amount of work. -- Michael