On Fri, Jul 8, 2016 at 3:06 AM, Andres Freund <and...@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.rouh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
