From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | robertmhaas(at)gmail(dot)com |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Problem in Parallel Bitmap Heap Scan? |
Date: | 2017-04-10 03:17:34 |
Message-ID: | 20170410031734.GB2845039@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Mar 25, 2017 at 09:55:21PM +1300, Thomas Munro wrote:
> On Sat, Mar 25, 2017 at 6:04 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > On Tue, Mar 21, 2017 at 5:51 PM, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> >> On Tue, Mar 21, 2017 at 4:47 PM, Thomas Munro
> >> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> >>> I noticed a failure in the inet.sql test while running the regression
> >>> tests with parallelism cranked up, and can reproduce it interactively
> >>> as follows. After an spgist index is created and the plan changes to
> >>> the one shown below, the query returns no rows.
> >>
> >> Thanks for reporting. Seems like we are getting issues related to
> >> TBM_ONE_PAGE and TBM_EMPTY.
> >>
> >> I think in this area we need more testing, reason these are not tested
> >> properly because these are not the natural case for parallel bitmap.
> >> I think in next few days I will test more such cases by forcing the
> >> parallel bitmap.
> >>
> >
> > Okay, is your testing complete?
> >
> >> Here is the patch to fix the issue in hand. I have also run the
> >> regress suit with force_parallel_mode=regress and all the test are
> >> passing.
> >>
> >
> > Thomas, did you get chance to verify Dilip's latest patch?
> >
> > I have added this issue in PostgreSQL 10 Open Items list so that we
> > don't loose track of this issue.
>
> The result is correct with this patch. I ran make installcheck then
> the same steps as above and the query result was correct after
> creating the index.
[Action required within three days. This is a generic notification.]
The above-described topic is currently a PostgreSQL 10 open item. Robert,
since you committed the patch believed to have created it, you own this open
item. If some other commit is more relevant or if this does not belong as a
v10 open item, please let us know. Otherwise, please observe the policy on
open item ownership[1] and send a status update within three calendar days of
this message. Include a date for your subsequent status update. Testers may
discover new open items at any time, and I want to plan to get them all fixed
well in advance of shipping v10. Consequently, I will appreciate your efforts
toward speedy resolution. Thanks.
[1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2017-04-10 03:18:36 | Re: strange parallel query behavior after OOM crashes |
Previous Message | Noah Misch | 2017-04-10 02:41:57 | Re: logical replication and SIGHUP |