Re: Inadequate executor locking of indexes
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: David Rowley <david.rowley@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Rushabh Lathia <rushabh.lathia@gmail.com>
Date: 2018-12-01T13:39:02Z
Lists: 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
Commits
-
Make queries' locking of indexes more consistent.
- 9c703c169a87 12.0 landed