On Sat, Jun 4, 2016 at 2:41 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Jun 2, 2016 at 1:34 AM, Michael Paquier > <michael.paqu...@gmail.com> wrote: >> This patch is shaped this way intentionally based on the feedback I >> received at PGCon (Robert and others). We could provide a routine that >> extensions call in _PG_init to register a new latch event name in >> shared memory, but I didn't see much use in doing so, take for example >> the case of background worker, it is possible to register a custom >> string for pg_stat_activity via pgstat_report_activity. One could take >> advantage of having custom latch wait names in shared memory if an >> extension has wait points with latches though... But I am still not >> sure if that's worth the complexity. > > I can't see how you could ever guarantee that it wouldn't just fail. > We allocate a certain amount of "slop" in the main shared memory > segment, but it's not infinite and can certainly be exhausted. It > seems like it would suck if you tried to load your extension and it > failed because there was no room left for more wait-point names. > Maybe it would suck less than not having wait-point names, but I'm not > really sure. I think we'd do better to get something that handles the > core stuff well and then consider extensions later or not at all.
Yeah, that's as well my line of thoughts on the matter since the beginning: keep it simple and done. What is written just after those words is purely hand-waving and I have no way to prove it, but my instinctive guess is that more than 90% of the real use cases where we need to track the latch waits in pgstat would be covered without the need of this extra shared memory infrastructure for extensions. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
