On Sat, 24 Nov 2018 at 05:25, Tom Lane <t...@sss.pgh.pa.us> wrote: > Now, after more thought, I believe that it's probably impossible > to have a plan tree in which ExecRelationIsTargetRelation would > return true at an indexscan node that's not underneath the ModifyTable > node. What *is* possible is that we have such an indexscan on a > different RTE for the same table. I constructed this admittedly > artificial example in the regression database: > > # explain with x1 as (select * from tenk1 t1 where unique1 = 42), > x2 as (update tenk1 t2 set two = 2 where unique2 = 11 returning *) > select * from x1,x2 where x1.ten = x2.ten;
Well, that problem exists with more than just indexes. Relations could be problematic too. An even more simple artificial example would be: select * from t1 inner join t1 t2 on t1.a=t2.a for update of t2; We could fix that in the executor by processing the rangetable in the planner, first throwing the whole thing into a hash table by Oid and finding the strongest lock level and applying that level to each (non-dummy) matching RangeTblEntry's rellockmode. While we're there we could add a new field for indexlockmode and do the same process on that. However... there might not be much point as this does nothing for the same problem that exists in parse analyze. That may be much harder or even impossible to fix. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services