On Mon, 2009-12-14 at 15:24 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On Mon, 2009-12-14 at 20:32 +0200, Heikki Linnakangas wrote:
> >>> I have ensured that they are always the same size, by definition, so no
> >>> need to check.
> >>
> >> How did you ensure that? The hash table has no hard size limit.
>
> > The hash table is in shared memory and the entry size is fixed. My
> > understanding was that this meant the hash table was fixed in size and
> > could not grow beyond the allocation. If that assumption was wrong, then
> > yes we could get an error. Is it?
>
> Entirely. The only thing the hash table size enters into is the sizing
> of overall shared memory --- different hash tables then consume space
> from the common pool, which includes not only the computed space
> requirements but a pretty hefty slop overhead. You can go beyond the
> original requested space if there is any slop left.
OK, thanks.
> For a number of shared hashtables that actually have a fixed set of
> entries, we avoid the risk of unexpected out-of-memory by forcing all
> the entries to come into existence during startup. If your table
> doesn't work that way then you cannot be sure of the exact point where
> it will get an out-of-memory failure.
The data structure was originally a list of fixed size, though is now a
shared hash table.
What is the best way of restricting the hash table to a maximum size?
Your last para makes me think there is a way, but I can't see it
directly. If there isn't a facility to do this and I need to add code,
should I add optional code into the dynahash.c to track size, or should
I add that in the data structure code that uses the hash functions (so,
internally or externally).
-- Simon Riggs www.2ndQuadrant.com
