On Sat, Jan 7, 2017 at 2:47 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Fri, Jan 6, 2017 at 11:08 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>> On Mon, Oct 3, 2016 at 11:00 AM, Michael Paquier
>> <michael.paquier@gmail.com> wrote:
>>> On Fri, Sep 16, 2016 at 6:56 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>>>> Yeah, I don't have a good solution for this problem so far.
>>>> We might need to improve group locking mechanism for the updating
>>>> operation or came up with another approach to resolve this problem.
>>>> For example, one possible idea is that the launcher process allocates
>>>> vm and fsm enough in advance in order to avoid extending fork relation
>>>> by parallel workers, but it's not resolve fundamental problem.
>>>
>>
>> I got some advices at PGConf.ASIA 2016 and started to work on this again.
>>
>> The most big problem so far is the group locking. As I mentioned
>> before, parallel vacuum worker could try to extend the same visibility
>> map page at the same time. So we need to make group locking conflict
>> in some cases, or need to eliminate the necessity of acquiring
>> extension lock. Attached 000 patch uses former idea, which makes the
>> group locking conflict between parallel workers when parallel worker
>> tries to acquire extension lock on same page.
>>
>
> How are planning to ensure the same in deadlock detector? Currently,
> deadlock detector considers members from same lock group as
> non-blocking. If you think we don't need to make any changes in
> deadlock detector, then explain why so?
>
Thank you for comment.
I had not considered necessity of dead lock detection support. But
because lazy_scan_heap actquires the relation extension lock and
release it before acquiring another extension lock, I guess we don't
need that changes for parallel lazy vacuum. Thought?
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center