Jeff Davis writes:
> On Mon, 2012-12-10 at 21:19 -0500, Tom Lane wrote:
>> I hadn't gone any further than to code and test the functions I listed.
>> If you are working on a complete patch, please press on.
> Attached. This fixes my test case[1] and uses the functions that you
> wrote. I made the
On Mon, 2012-12-10 at 21:19 -0500, Tom Lane wrote:
> I hadn't gone any further than to code and test the functions I listed.
> If you are working on a complete patch, please press on.
Attached. This fixes my test case[1] and uses the functions that you
wrote. I made them static because I couldn't
Jeff Davis writes:
> On Mon, 2012-12-10 at 20:27 -0500, Tom Lane wrote:
>> That does seem like a good idea. We need one for an int-sized result
>> too, to fix the original problem in init_htab. So I propose these
>> functions:
> Looks good to me. One other corner case in the version of the patc
On Mon, 2012-12-10 at 20:27 -0500, Tom Lane wrote:
> Jeff Davis writes:
> > It looks like all of the callers, except two, immediately shift the
> > result. So perhaps it would be better to make a new function (something
> > like "ceil_pow2") that returns the lowest power of two greater than or
> >
Jeff Davis writes:
> It looks like all of the callers, except two, immediately shift the
> result. So perhaps it would be better to make a new function (something
> like "ceil_pow2") that returns the lowest power of two greater than or
> equal to the input, and it can return a long (bounded to +LO
Jeff Davis writes:
> On Sun, 2012-12-09 at 17:45 -0500, Tom Lane wrote:
>> Alternatively, maybe we should hack my_log2 to do that bounding.
>> As-is, it seems like trouble waiting to happen. This won't protect
>> init_htab, which needs the shift result to fit in int not long.
>> But my_log2 is j
On Sun, 2012-12-09 at 17:45 -0500, Tom Lane wrote:
> Yeah. After looking at other uses of my_log2, it seems like
> hash_estimate_size and hash_select_dirsize probably should also
> bound their inputs to avoid overflow of 1 << my_log2() calculations.
>
> Alternatively, maybe we should hack my_log
Jeff Davis writes:
> If nbuckets is around 2^30+1, which can happen if work_mem is very high,
> then:
> nbuckets = 1 << my_log2(lnbuckets);
> ends up as 1 << 31, which is negative, leading to a SIGFPE on my
> machine, but I think it can also lead to an infinite loop or a crash
> (after corrupt
If nbuckets is around 2^30+1, which can happen if work_mem is very high,
then:
nbuckets = 1 << my_log2(lnbuckets);
ends up as 1 << 31, which is negative, leading to a SIGFPE on my
machine, but I think it can also lead to an infinite loop or a crash
(after corrupting the HASHHDR).
The only si
