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.
--
Michael