Re: Parallel bitmap heap scan

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com>, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel bitmap heap scan
Date: 2017-01-24 04:48:29
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Mon, Jan 23, 2017 at 1:52 PM, Haribabu Kommi
<kommi(dot)haribabu(at)gmail(dot)com> wrote:
> I reviewed 0002-hash-support-alloc-free-v12.patch, some minor comments.
> - SH_TYPE *tb;
> - uint64 size;
> + SH_TYPE *tb;
> + uint64 size;
> The above change may not be required.
> + if (tb->alloc)
> + {
> + tb->alloc->HashFree(tb->data, tb->alloc->args);
> + pfree(tb->alloc);
> + }
> The above code tries to free the tb->alloc memory. In case if the user
> has provide the alloc structure to SH_CREATE function and the same
> pointer is stored in the tb structure. And in free function freeing that
> memory may cause problem.
> So either explicitly mentioning that the input must a palloc'ed data or
> by default allocate memory and copy the input data into allocated
> memory.

I have changed as per the comments. 0002 and 0003 are changed, 0001 is
still the same.

Dilip Kumar

Attachment Content-Type Size
0001-opt-parallelcost-refactoring-v13.patch application/octet-stream 4.9 KB
0002-hash-support-alloc-free-v13.patch application/octet-stream 6.3 KB
0003-parallel-bitmap-heap-scan-v13.patch application/octet-stream 44.7 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Haribabu Kommi 2017-01-24 04:55:08 Re: macaddr 64 bit (EUI-64) datatype support
Previous Message Michael Paquier 2017-01-24 04:45:38 Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal