| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
| Cc: | Victor Yegorov <vyegorov(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #15290: Stuck Parallel Index Scan query |
| Date: | 2018-07-25 02:08:05 |
| Message-ID: | 20180725020805.z56klx2dqewggrua@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 2018-07-25 14:04:11 +1200, Thomas Munro wrote:
> Ok, I see it:
>
> /* check for interrupts while we're not
> holding any buffer lock */
> CHECK_FOR_INTERRUPTS();
> /* step right one page */
> so->currPos.buf = _bt_getbuf(rel, blkno, BT_READ);
> ...
> /* nope, keep going */
> if (scan->parallel_scan != NULL)
> {
> status = _bt_parallel_seize(scan, &blkno);
>
> That leads to a condition variable wait, while we still hold that
> buffer lock. That prevents interrupts. Oops.
Heh, guessed right. I kinda wonder if we shouldn't add a
CHECK_FOR_INTERRUPTS_FOR_REALZ() that asserts if interrupts aren't
held. There are plenty places where we rely on that being the case, for
correctness.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2018-07-25 02:49:56 | Re: LLVM jit and matview |
| Previous Message | Thomas Munro | 2018-07-25 02:04:11 | Re: BUG #15290: Stuck Parallel Index Scan query |