On Sat, Jan 7, 2017 at 2:47 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Fri, Jan 6, 2017 at 11:08 PM, Masahiko Sawada <sawada.m...@gmail.com> 
> wrote:
>> On Mon, Oct 3, 2016 at 11:00 AM, Michael Paquier
>> <michael.paqu...@gmail.com> wrote:
>>> On Fri, Sep 16, 2016 at 6:56 PM, Masahiko Sawada <sawada.m...@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?


Masahiko Sawada
NTT Open Source Software Center

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to