Thread: Indexscan failed assert caused by using index without lock
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;
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?
=?UTF-8?B?6auY5aKe55Cm?= <pgf00a@gmail.com> writes: > Following example can reproduce the problem: Yeah, this is being discussed at https://www.postgresql.org/message-id/flat/19465.1541636036@sss.pgh.pa.us regards, tom lane