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? Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
