Re: Inadequate executor locking of indexes - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Inadequate executor locking of indexes
Date
Msg-id CAA4eK1+r9YXqRU5kOUz6twYVgXjOY-mXuaF-roBobtvPnF4nkw@mail.gmail.com
Whole thread Raw
In response to Re: Inadequate executor locking of indexes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Nov 23, 2018 at 9:55 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Thinking more about this, the problem I noted previously about two of
> these solutions not working if the index scan node is not physically
> underneath the ModifyTable node actually applies to all three :-(.
> It's a slightly different issue for #2, namely that what we risk is
> first taking AccessShareLock and then upgrading to RowExclusiveLock.
> Since there are places (not many) that take ShareLock on indexes,
> this would pose a deadlock risk.
>

Can you be a bit more specific on what exact deadlock risk you are
seeing here as Amit L asked about it and I am also curious to know?
One way I could see is:

Session-1
begin;
Lock table foo in Access Share Mode;

Session-2
begin;
Lock table foo in Share Mode;

Session-1
Lock table foo in Row Exclusive Mode;  --here it will wait for session-2

Session-2
Lock table foo in Access Exclusive Mode;  --here it will lead to deadlock


-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: jsonpath
Next
From: Peter Eisentraut
Date:
Subject: Re: pg_stat_ssl additions