On Sat, Jun 4, 2016 at 2:41 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Jun 2, 2016 at 1:34 AM, Michael Paquier
> <michael.paquier@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
