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. It only matters if you're running multiple extensions that all use LWLock tranches and you need to distinguish between waits on their various LWLocks. But since LWLock contention is something we hope will be infrequent I'm just not sure that case is common enough to justify building a lot of mechanism. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers