2012/11/30 Markus Wanner <markus@bluegap.ch>:
> On 11/30/2012 03:16 PM, Kohei KaiGai wrote:
>> This feature does not enforce them to implement with this new framework.
>> If they can perform as separate daemons, it is fine enough.
>
> I'm not clear on what exactly you envision, but if a process needs
> access to shared buffers, it sounds like it should be a bgworker. I
> don't quite understand why that process also wants a libpq connection,
> but that's certainly doable.
>
It seemed to me you are advocating that any use case of background-
worker can be implemented with existing separate daemon approach.
What I wanted to say is, we have some cases that background-worker
framework allows to implement such kind of extensions with more
reasonable design.
Yes, one reason I want to use background-worker is access to shared-
memory segment. Also, it want to connect databases simultaneously
out of access controls; like as autovacuum. It is a reason why I'm saying
SPI interface should be only an option, not only libpq.
(If extension choose libpq, it does not take anything special, does it?)
>> But it is not all the cases where we want background workers being tied
>> with postmaster's duration.
>
> Not wanting a process to be tied to postmaster's duration is a strong
> indication that it better not be a bgworker, I think.
>
It also probably means, in case when a process whose duration wants to
be tied with duration of postmaster, its author can consider to implement
it as background worker.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
