Re: src/test/subscription/t/002_types.pl hanging on particular environment

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

The subscription "DDL" commands and monitoring functions need access to
that info. Note that the synchronization workers are not even started by
launcher (I experimented with doing that but it slows the process of
synchronization quite considerably) so it can't manage them unless the
handle is accessible via IPC.

>> 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?
>

Yes. There is no reason why replication should stop because of launcher
restart.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services