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