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?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com