Re: Tracking wait event for latches

On Thu, Jun 2, 2016 at 1:34 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)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