On Tue, Sep 19, 2017 at 6:29 PM, Petr Jelinek <petr.jeli...@2ndquadrant.com> wrote: > On 19/09/17 14:33, 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: >>> >>>> So, frankly, I think we would be best off losing the "logical rep >>>> worker slot" business altogether, and making do with just bgworker >>>> slots. >> >> I think that would be cleaner as compared to what we have now. >> >>>> 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. >>> >> >> Yeah, but you could have used the way we do for parallel query where >> we setup dsm and share all such information. You can check the logic >> of execparallel.c and parallel.c to see how we do all such stuff for >> parallel query. >> > > I don't understand how DSM helps in this case (except perhaps the memory > allocation being dynamic rather than static). We still need this shared > memory area to be accessible from other places than launcher (the > paralllel query has one lead which manages everything, that's not true > for logical replication) >
I am not much aware of this area. Can you explain what other usages it has apart from in the process that has launched the worker and in worker itself? > and we need it to survive restart of launcher > for example, so all the current issues will stay. > Do you mean to say that you want to save this part of shared memory across restart of launcher? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers