Craig Ringer <craig@2ndquadrant.com> writes: > On 19 September 2017 at 18:04, Petr Jelinek <petr.jelinek@2ndquadrant.com> > wrote: >> If you are asking why they are not identified by the >> BackgroundWorkerHandle, then it's because it's private struct and can't >> be shared with other processes so there is no way to link the logical >> worker info with bgworker directly.
> I really want BackgroundWorkerHandle to be public, strong +1 from me.
I'm confused about what you think that would accomplish. AFAICS, the point of BackgroundWorkerHandle is to allow the creator/requestor of a bgworker to verify whether or not the slot in question is still "owned" by its request. This is necessarily not useful to any other process, since they didn't make the request.
I'm using shm_mq in a sort of "connection accepter" role, where a pool of shm_mq's are attached to by a long lived bgworker. Other backends, both bgworkers and normal user backends, can find a free slot and attach to it to talk to the long lived bgworker. These other backends are not necessarily started by the long lived worker, so it doesn't have a BackgroundWorkerHandle for them.
If the BackgroundWorkerHandle for the long-lived bgworker is copied to a small static control shmem segment, the connecting workers can use that to reliably bail out if the long-lived worker dies.
The thought I had in mind upthread was to get rid of logicalrep slots in favor of expanding the underlying bgworker slot with some additional fields that would carry whatever extra info we need about a logicalrep worker. Such fields could also be repurposed for additional info about other kinds of bgworkers, when (not if) we find out we need that.
That sounds OK to me personally for in-core logical rep, but it's really Petr and Peter who need to have a say here, not me.
