On 20/09/17 05:53, Tom Lane wrote:
> 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 works pretty well as unique identifier of the bgworker which can be
used to check if the specific bgworker process is the one we think it is
and that would work even across processes if it could be shared.
Bgworker slots don't help with that as they can be replaced by different
worker between calls, same goes for PID. It technically does not have to
be public struct, just serialize-able/copyable so knowing size of the
struct ought to be enough for that.
> 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.
>
Well, that would be nice but those slots are in shared memory so it's
not exactly easy to allow other modules to add arbitrary data there.
Maybe we could add just one field that holds DSM handle (or DSA handle)
to whatever dynamic shared memory is allocated for that slot. I don't
know enough about inner working of DSM to say for sure if that's
feasible or not though.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers