Re: Issue with bgworker, SPI and pgstat_report_stat
От | Julien Rouhaud |
---|---|
Тема | Re: Issue with bgworker, SPI and pgstat_report_stat |
Дата | |
Msg-id | 33deeecb-4e13-5834-d1c4-b30df13cbf8b@dalibo.com обсуждение исходный текст |
Ответ на | Re: Issue with bgworker, SPI and pgstat_report_stat (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Issue with bgworker, SPI and pgstat_report_stat
|
Список | pgsql-hackers |
On 08/07/2016 01:53, Michael Paquier wrote: > On Fri, Jul 8, 2016 at 3:06 AM, Andres Freund <andres@anarazel.de> wrote: >> On 2016-07-07 14:04:36 -0400, Robert Haas wrote: >>> On Thu, Jul 7, 2016 at 1:52 PM, Julien Rouhaud >>> <julien.rouhaud@dalibo.com> wrote: >>>> Should a bgworker modifing data have to call pgstat_report_stat() to >>>> avoid this problem? I don't find any documentation suggesting it, and it >>>> seems that worker_spi (used as a template for this bgworker and I >>>> suppose a lot of other one) is also affected. >>> >>> That certainly seems like the simplest fix. Not sure if there's a better one. >> >> I think a better fix would be to unify the startup & error handling >> code. We have way to many slightly diverging copies. But that's a bigger >> task, so I'm not protesting against making a more localized fix. > > It seems to me that the only fix is to have the bgworker call > pgstat_report_stat() and not mess up with the in-core backend code. > Personally, I always had the image of a bgworker to be an independent > process, so when it wants to do something, be it mimicking normal > backends, it should do it by itself. Take the example of SIGHUP > processing. If the bgworker does not ProcessConfigFile() no parameters > updates will happen in the context of the bgworker. > I'm not opposed, but in this case we should also provide a proper documentation of all the required actions to mimick normal backends. -- Julien Rouhaud http://dalibo.com - http://dalibo.org
В списке pgsql-hackers по дате отправления: