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?
--
GaoZengqi
pgf00a(at)gmail(dot)com
zengqigao(at)gmail(dot)com