Re: Inadequate executor locking of indexes
От | Amit Kapila |
---|---|
Тема | Re: Inadequate executor locking of indexes |
Дата | |
Msg-id | CAA4eK1+r9YXqRU5kOUz6twYVgXjOY-mXuaF-roBobtvPnF4nkw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Inadequate executor locking of indexes (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: