Re: Reduced power consumption in autovacuum launcher process
От | Peter Geoghegan |
---|---|
Тема | Re: Reduced power consumption in autovacuum launcher process |
Дата | |
Msg-id | CAEYLb_X8ZyyOnv8jjtFRJC7TDrhcY5TYyjo61mcddmeCsD+p5g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Reduced power consumption in autovacuum launcher process (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Reduced power consumption in autovacuum launcher process
Re: Reduced power consumption in autovacuum launcher process |
Список | pgsql-hackers |
Attached is revision of this patch that now treats the latch in PGPROC, waitLatch, as the generic "process latch", rather than just using it for sync rep; It is initialised appropriately as a shared latch generically, within InitProcGlobal(), and ownership is subsequently set within InitProcess(). We were doing so before, though only for the benefit of sync rep. The idea here is to have a per-process latch to guard against time-out invalidation issues from within each generic signal handler, by calling SetLatch() on our generic latch there, much as we already do from within non-generic archiver process signal handlers on the archiver's static, non-generic latch (the archiver has its MyProc pointer set to NULL, and we allow for the possibility that generic handlers may be registered within processes that have a NULL MyProc - though latch timeout invalidation issues then become the responsibility of the process exclusively, just as is currently the case with the archiver. In other words, they better not register a generic signal handler). It doesn't really matter that the SetLatch() call will usually be unnecessary, because, as Heikki once pointed out, redundantly setting a latch that is already set is very cheap. We don't check if it's set directly in advance of setting the latch, because the Latch struct is "logically opaque" and there is no "public function" to check if it's set, nor should there be; the checking simply happens in SetLatch(). On 18 July 2011 20:06, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: > Right, we can easily change the timeout argument to be in milliseconds > instead of microseconds. I've done so in this latest revision as a precautionary measure. I don't see much point in sub-millisecond granularity, and besides, the Windows implementation will not provide that granularity anyway as things stand. Thoughts? -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
Вложения
В списке pgsql-hackers по дате отправления: