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.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to