| From: | 高增琦 <pgf00a(at)gmail(dot)com> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Indexscan failed assert caused by using index without lock |
| Date: | 2019-03-30 06:22:59 |
| Message-ID: | CAFmBtr35nsmbKvb_FEjQndbieMiser+zBLhhS7_a9pcdSeVvZA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Павлухин Иван | 2019-03-30 06:35:39 | Column lookup in a row performance |
| Previous Message | Alvaro Herrera | 2019-03-30 05:09:47 | Re: monitoring CREATE INDEX [CONCURRENTLY] |