On 11/30/2012 03:58 PM, Kohei KaiGai wrote: > It seemed to me you are advocating that any use case of background- > worker can be implemented with existing separate daemon approach.
That sounds like a misunderstanding. All I'm advocating is that only 3rd-party processes with a real need (like accessing shared memory) should run under the postmaster. > 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. I absolutely agree to that. And I think I can safely claim to be the first person to publish a patch that provides some kind of background worker infrastructure for Postgres. > 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. Yeah, that's the entire reason for background workers. For clarity and differentiation, I'd add: .. without having a client connection. That's what makes them *background* workers. (Not to be confused with the frontend vs backend differentiation. They are background backends, if you want). > It is a reason why I'm saying > SPI interface should be only an option, not only libpq. I'm extending that to say extensions should better *not* use libpq. After all, they have a more direct access, already. > 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. I personally don't count that as a real need. There are better tools for this job; while there clearly are dangers in (ab)using the postmaster to do it. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
