Robert Haas writes:
> On Fri, Feb 2, 2018 at 3:01 PM, Tom Lane wrote:
>> Do you mind if I change that Assert to a run-time test?
> Hrm, I guess I could have done something like
> shm_toc_lookup(pcxt->toc, PARALLEL_KEY_ERROR_QUEUE, (pcxt->nworkers ==
> 0)).
OK, that'd work too. I'll make it so.
On Fri, Feb 2, 2018 at 3:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> That turned out to produce more than one problem. I find that the
>> select_parallel test then fails like this:
>> ERROR: could not find key 18446744073709486082 in shm TOC at 0x10be98040
>> The fix for that problem seems
Robert Haas writes:
> That turned out to produce more than one problem. I find that the
> select_parallel test then fails like this:
> ERROR: could not find key 18446744073709486082 in shm TOC at 0x10be98040
> The fix for that problem seems to be:
> /* Recreate error queues. */
> erro
On Tue, Nov 28, 2017 at 9:45 AM, Dilip Kumar wrote:
>> I haven't checked whether this fixes the bug, but if it does, we can
>> avoid introducing an extra branch in BitmapHeapNext.
>
> With my test it's fixing the problem.
I tested it some more and found that, for me, it PARTIALLY fixes the
proble
On Tue, Nov 28, 2017 at 7:13 PM, Robert Haas wrote:
> On Tue, Nov 28, 2017 at 2:32 AM, Dilip Kumar
> wrote:
> > I think BitmapHeapScan check whether dsa is valid or not if DSA is not
> > valid then it should assume it's non-parallel plan.
> >
> > Attached patch should fix the issue.
>
> So, cre
On Tue, Nov 28, 2017 at 2:32 AM, Dilip Kumar wrote:
> I think BitmapHeapScan check whether dsa is valid or not if DSA is not
> valid then it should assume it's non-parallel plan.
>
> Attached patch should fix the issue.
So, create the pstate and then pretend we didn't? Why not just avoid
creati
On Tue, Nov 28, 2017 at 4:18 AM, Thomas Munro wrote:
> On Tue, Nov 28, 2017 at 10:05 AM, Jakub Glapa
> wrote:
> > As for the crash. I dug up the initial log and it looks like a
> segmentation
> > fault...
> >
> > 2017-11-23 07:26:53 CET:192.168.10.83(35238):user@db:[30003]: ERROR:
> too
> > many