PROPOSED GENERALISED WORKER MANAGEMENT
----
Finally I'm wondering if there's any interest in generalizing the logical rep worker management for other bgworkers. I've done a ton of work with worker management and it's something I'm sure I could take on but I don't want to write it without knowing there's some chance of acceptance.
The general idea is to provide a way for bgworkers to start up managers for pools / sets of workers. They launch them and have a function they can call in their mainloop that watches their child worker states, invoking callbacks when they fail to launch, launch successfully, exit cleanly after finishing their work, or die with an error. Workers are tracked in a shmem seg where the start of the seg must be a key struct (akin to how the hash API works). We would provide calls to look up a worker shmem struct by key, signal a worker by key, wait for a worker to exit (up to timeout), etc. Like in the logical rep code, access to the worker registration shmem would be controlled by LWLock. The extension code can put whatever it wants in the worker shmem entries after the key, including various unions or whatever - the worker management API won't care.
This abstracts all the low level mess away from bgworker implementations and lets them focus on writing the code they want to run.
I'd probably suggest doing so by extracting the logical rep worker management, and making the logical rep code use the generalized worker management. So it'd be proven, and have in core users.
