Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix inadequacies in recentlyadded wait events
От | David Fetter |
---|---|
Тема | Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix inadequacies in recentlyadded wait events |
Дата | |
Msg-id | 20170809151837.GF10454@fetter.org обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix inadequacies in recently added wait events (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix inadequacies in recentlyadded wait events
|
Список | pgsql-hackers |
On Wed, Aug 09, 2017 at 10:56:50AM -0400, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > On Wed, Aug 9, 2017 at 10:14 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Thomas Munro <thomas.munro@enterprisedb.com> writes: > >>> 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? > > >> Adding overhead to every developer's every test cycle doesn't > >> sound like a win. > > > If it takes 100ms, nobody's gonna notice. > > I doubt running a perl script that analyzes the entire backend > source code is gonna take 100ms. What would be a reasonable maximum amount of time for such a check to take? Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
В списке pgsql-hackers по дате отправления: