On 19/09/17 16:30, Amit Kapila wrote: > On Tue, Sep 19, 2017 at 3:34 PM, Petr Jelinek > <petr.jeli...@2ndquadrant.com> wrote: >> n 18/09/17 18:42, Tom Lane wrote: >>> Amit Kapila <amit.kapil...@gmail.com> writes: >>>> On Mon, Sep 18, 2017 at 7:46 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> So, frankly, I think we would be best off losing the "logical rep >>> worker slot" business altogether, and making do with just bgworker >>> slots. The alternative is getting the postmaster involved in cleaning >>> up lrep slots as well as bgworker slots, and I'm going to resist >>> any such idea strongly. That way madness lies, or at least an >>> unreliable postmaster --- if we need lrep slots, what other forty-seven >>> data structures are we going to need the postmaster to clean up >>> in the future? >>> >>> I haven't studied the code enough to know why it grew lrep worker >>> slots in the first place. Maybe someone could explain? >>> >> >> I am not quite sure I understand this question, we need to store >> additional info about workers in shared memory so we need slots for that. >> >> 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. >> > > Not sure, but can't we identify the actual worker slot if we just have > pid of background worker? IIUC, you need access to > BackgroundWorkerHandle by other processes, so that you can stop them > like in case of drop subscription command. If so, then, might be > storing pid can serve the purpose. >
I don't think that pid can be trusted to belong to same process between the calls, if we could we would not need BackgroundWorkerHandle. -- 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
