On Tue, Sep 19, 2017 at 6:29 PM, Petr Jelinek
<petr.jelinek@2ndquadrant.com> wrote:
> On 19/09/17 14:33, Amit Kapila wrote:
>> On Tue, Sep 19, 2017 at 3:34 PM, Petr Jelinek
>> <petr.jelinek@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
