On Sat, Aug 3, 2013 at 6:31 AM, Andrew Tipton <and...@kiwidrew.com> wrote: > Robert: any chance you could share a few more details on the enhancements > you're planning for bgworkers? I seem to recall reading that communicating > with the dynamic bgworkers after they had been launched was next on your > agenda...
Yeah, it is. I'm working on a patch to allow additional shared memory segments to be created on the fly. The idea I'm working with is that a backend that plans to launch a worker will first create a dynamic shared memory segment, then pass the ID of that segment to the worker via bgw_main_arg. The worker will map the segment, and then the two processes can use that to communicate. My thought is to create a queue abstraction that sits on top of the dynamic shared memory infrastructure, so that you can set aside a portion of your dynamic shared memory segment to use as a ring buffer and send messages back and forth with using some kind of API along these lines: extern void dsm_queue_send(dsm_queue *, char *data, uint64 len); extern uint64 dsm_queue_receive(dsm_queue *, char **dataptr); It would also be possible to implement message sending and receiving using pipes, but I'm leaning away from that because it would require even more OS-dependent code than I'm already having to write, and writing OS-dependent shim layers is one of the world's less-rewarding coding tasks; and also because I think it will be easier to achieve zero-copy semantics using shared memory. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
