2012/11/30 Markus Wanner <mar...@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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers