Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix inadequacies in recentlyadded wait events
От | Thomas Munro |
---|---|
Тема | Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix inadequacies in recentlyadded wait events |
Дата | |
Msg-id | CAEepm=1Pto4hOHZgQcC7eFxnQkb_qNuGCQMxK=zJoLZ=+8DELw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix inadequacies in recentlyadded wait events (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix inadequacies in recently added wait events
|
Список | pgsql-hackers |
On Wed, Aug 9, 2017 at 6:42 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Tue, Aug 8, 2017 at 11:35 PM, Alvaro Herrera > <alvherre@2ndquadrant.com> wrote: >>> All of the above seem like good candidates for a checker script in >>> src/tools/check_XXX.pl, a bit like the others I've talked about >>> recently [1][2]. >> >> Yeah, that's one idea, but I think it'd be better to have all these >> things be generated content from a single "wait_events.txt" file, like >> src/backend/utils/errcodes.txt which gives birth to a whole host of >> different files. > > I would prefer that. Check scripts would tend to be never run. So is > there somebody willing to work on that? Or should I as I am > responsible to increasing the number of wait events? Yeah, that may well be a better idea in this case. On the other hand it wouldn't catch multiple users of the same wait event, so both things could be useful. As for whether hypothetical check scripts would ever be run, I was thinking we should stick them under some make target that developers run all the time anyway -- perhaps "check". Shouldn't we catch simple mechanically detectable problems as early in the pipeline as possible? -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: