Re: Parallel bitmap heap scan - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Parallel bitmap heap scan
Date
Msg-id CA+TgmoY8AzA65F3cEtVyN12wp-GVNAtXe0d-vnJDZ0oOP9LCig@mail.gmail.com
Whole thread Raw
In response to Parallel bitmap heap scan  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: Parallel bitmap heap scan  (Dilip Kumar <dilipbalaut@gmail.com>)
List pgsql-hackers
On Mon, Mar 27, 2017 at 5:02 AM, Dilip Kumar <dilipbalaut@gmail.com> wrote:
> On Mon, Mar 27, 2017 at 12:53 PM, Rafia Sabih
> <rafia.sabih@enterprisedb.com> wrote:
>> Recently, on testing TPC-H 300 scale factor I stumbled on to a error
>> for Q6, the test environment is as follows,
>> work_mem = 1GB,
>> shared_buffers = 10 GB,
>> Effective_cache_size = 10GB
>> random_page_cost = seq+page_cost =0.1
>>
>> The error message is, ERROR:  invalid DSA memory alloc request size 1610612740
>> In case required, stack trace is as follows,
>
> Thanks for reporting.  In pagetable_allocate, DSA_ALLOC_HUGE flag were
> missing while allocating the memory from the DSA.  I have also handled
> the NULL pointer return from dsa_get_address.
>
> Please verify with the attached patch.

Failing to pass DSA_ALLOC_HUGE is an obvious oversight, but I think
the ptbase == NULL check shouldn't be needed, because we're not
passing DSA_ALLOC_NO_OOM.  And that's good, because this is going to
be called from SH_CREATE, which isn't prepared for a NULL return
anyway.

Am I all wet?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [COMMITTERS] pgsql: Improve access to parallel queryfrom procedural languages.
Next
From: Peter Eisentraut
Date:
Subject: Re: perlcritic