Re: Issue with bgworker, SPI and pgstat_report_stat

From: Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(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-10 18:36:51
Message-ID: 33deeecb-4e13-5834-d1c4-b30df13cbf8b@dalibo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 08/07/2016 01:53, Michael Paquier wrote:
> 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.
>

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-07-10 23:34:15 Re: can we optimize STACK_DEPTH_SLOP
Previous Message Julien Rouhaud 2016-07-10 18:19:16 Re: PSA: Systemd will kill PostgreSQL