Re: RFC: replace pg_stat_activity.waiting with something more descriptive
От | Robert Haas |
---|---|
Тема | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
Дата | |
Msg-id | CA+TgmobET4H3aJ1qQfLPy0fU9rTBTQCmUVEbHaokzPP_U_==mQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RFC: replace pg_stat_activity.waiting with something more descriptive (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: RFC: replace pg_stat_activity.waiting with something
more descriptive
Re: RFC: replace pg_stat_activity.waiting with something more descriptive Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
Список | pgsql-hackers |
On Tue, Jul 28, 2015 at 3:28 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote: > * The patch requires that the LWLOCK_INDIVIDUAL_NAMES array is kept in sync > with the list of individual locks in lwlock.h. Sooner or later someone will > add an LWLock and forget to update the names-array. That needs to be made > less error-prone, so that the names are maintained in the same place as the > #defines. Perhaps something like rmgrlist.h. This is a good idea, but it's not easy to do in the style of rmgrlist.h, because I don't believe there's any way to define a macro that expands to a preprocessor directive. Attached is a patch that instead generates the list of macros from a text file, and also generates an array inside lwlock.c with the lock names that gets used by the Trace_lwlocks stuff where applicable. Any objections to this solution to the problem? If not, I'd like to go ahead and push this much. I can't test the Windows changes locally, though, so it would be helpful if someone could check that out. > * Instead of having LWLOCK_INDIVIDUAL_NAMES to name "individual" locks, how > about just giving each one of them a separate tranche? I don't think it's good to split things up to that degree; standardizing on one name per fixed lwlock and one per tranche otherwise seems like a good compromise to me. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-hackers по дате отправления: