Re: bg worker: overview

Hi,

On 07/23/2010 09:45 PM, Dimitri Fontaine wrote:
> Yeah, I guess user daemons would have to be workers, not plugins you
> want to load into the coordinator.

Okay.

>> On the other side, the background workers have a connection to exactly
>> one database. They are supposed to do work on that database.
>
> Is that because of the way backends are started, and to avoid having to
> fork new ones too often?

For one, yes, I want to avoid having to start ones too often. I did look
into letting these background workers switch the database connection,
but that turned out not to be worth the effort.

Would you prefer a background worker that's not connected to a database,
or why are you asking?

>> The background workers can easily load external libraries - just as a
>> normal backend can with LOAD. That would also provide better
>> encapsulation (i.e. an error would only tear down that backend, not the
>> coordinator). You'd certainly have to communicate between the
>> coordinator and the background worker. I'm not sure how match that fits
>> your use case.
>
> Pretty well I think.

Go ahead, re-use the background workers. That's what I've published them
for ;-)

> Yeah. The connection pool is better outside of code. Let's think PGQ and
> a internal task scheduler first, if we think at any generalisation.

To be honest, I still don't quite grok the concept behind PGQ. So I
cannot really comment on this.

Regards

Markus Wanner