Re: Parallel Index Scan vs BTP_DELETED and BTP_HALF_DEAD
Thomas Munro <thomas.munro@enterprisedb.com>
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Kuntal Ghosh <kuntalghosh.2007@gmail.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2017-12-13T03:25:40Z
Lists: pgsql-hackers
On Wed, Dec 13, 2017 at 4:20 PM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > On Wed, Dec 13, 2017 at 3:41 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> Good. I hope that the patch I have posted above is able to resolve >> this problem. I am asking as you haven't explicitly mentioned that. > > I can confirm that your patch fixes the problem for forward scans. > That is, I can see it reaching the BTP_DELETED case via an extra LOG > statement I added, and it worked correctly. Good. > > I don't know how to make it hit the backwards scan case. I can get a > backward scan in a worker by changing the query to "select count(*) > from (select * from jobs where id + 1 > id order by status desc) ss" > but I suspect that _bt_walk_left() may be hiding deleted pages from us > so the condition may not be reachable with this technique. Hmm, no that's not right: clearly it can return half-dead or deleted pages to the caller. So I don't know why I never seem to encounter any, despite concurrent vacuums producing them; maybe something to do with the interlocking you get with vacuum when you traverse the btree by walking left -- my btree-fu is not yet strong enough. -- Thomas Munro http://www.enterprisedb.com
Commits
-
Fix parallel index scan hang with deleted or half-dead pages.
- 884a60840cd6 11.0 landed
- 192ffe1cbd4a 10.2 landed