From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: simplehash: tb->sizemask = 0 |
Date: | 2017-11-28 03:53:41 |
Message-ID: | 16907.1511841221@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
> I'm a bit puzzled by this code in SH_COMPUTE_PARAMETERS:
> if (tb->size == SH_MAX_SIZE)
> tb->sizemask = 0;
> else
> tb->sizemask = tb->size - 1;
> Doesn't that mean that with SH_MAX_SIZE we end up with sizemask being 0
> (i.e. no bits set)?
Yeah, which is very obviously broken: for one thing, the Asserts
in SH_NEXT/SH_PREV would surely go off.
(Why are those assertions, anyway, and not test-and-elog?
I do not think an assertion failure is a suitable way to
report "hash table full".)
> I don't think we're building hash tables with 2^32 buckets, though.
What this proves is that nobody has ever tested the behavior at
SH_MAX_SIZE. I would suggest building a test version with that
set small enough to be conveniently reachable, and then exercising
the behavior as the limit is approached and reached.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2017-11-28 04:38:29 | Re: Add RANGE with values and exclusions clauses to the Window Functions |
Previous Message | Ashutosh Bapat | 2017-11-28 03:31:09 | Re: [HACKERS] Transactions involving multiple postgres foreign servers |