Following example can reproduce the problem:
```
create table d(a int);
create index di on d(a);
set enable_seqscan=off;
set enable_bitmapscan to off;
prepare p as delete from d where a=3;
execute p;
execute p;
```
The reason is that: ExecInitIndexScan will not lock index because it thinks InitPlan
already write-locked index. But in some cases, such as DELETE+cache plan will
not lock index, then failed assert.
Some thoughts on how to fix it:
1. Disable the optimization in ExecInitModifyTable, don't skip ExecOpenIndices for DELETE
2. For DELETE, instead of open indices, just lock them
3. Lock index of target rel in ExecInitIndexScan for DELETE
PS: another question, why does ExecCloseIndices release index lock instead of
keeping them?