Re: Issue with bgworker, SPI and pgstat_report_stat

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Marc Cousin <marc(dot)cousin(at)dalibo(dot)com>
Subject: Re: Issue with bgworker, SPI and pgstat_report_stat
Date: 2016-07-07 23:53:12
Message-ID: CAB7nPqTXR-eKMZvyMwYDf097KXR0-Gn82YS5KV-H0haw52n1Ow@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 8, 2016 at 3:06 AM, Andres Freund <andres(at)anarazel(dot)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(dot)rouhaud(at)dalibo(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2016-07-08 00:14:00 Re: A Modest Upgrade Proposal
Previous Message Joshua D. Drake 2016-07-07 23:48:28 Re: A Modest Upgrade Proposal