Re: Our naming of wait events is a disaster.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Our naming of wait events is a disaster.
Дата
Msg-id 14023.1589486333@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Our naming of wait events is a disaster.  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Our naming of wait events is a disaster.  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> That being said, my view of this system is that it's good to document
> the wait events that we have, but also that there are almost certainly
> going to be cases where we can't say a whole lot more than "go read
> the code," or at least not without an awful lot of work.

Can't disagree with that.

> I think
> there's a reasonable chance that someone who sees a lot of ClientRead
> or DataFileWrite wait events will have some idea what kind of problem
> is indicated, even without consulting the documentation and even
> moreso if we have some good documentation which they can consult. But
> I don't know what anybody's going to do if they see a lot of
> OldSerXidLock or AddinShmemInitLock contention.

I submit that at least part of the problem is precisely one of crappy
naming.  I didn't know what OldSerXidLock did either, until yesterday
when I dug into the code to find out.  If it's named something like
"SerialSLRULock", then at least somebody who has heard of SLRUs will
have an idea of what is indicated.  And we are exposing the notion
of SLRUs pretty prominently in the monitoring docs as of v13, so that's
not an unreasonable presumption.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: new heapcheck contrib module
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: new heapcheck contrib module