Re: Hot Standby, release candidate? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Hot Standby, release candidate?
Date
Msg-id 13308.1260822261@sss.pgh.pa.us
Whole thread Raw
In response to Re: Hot Standby, release candidate?  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Hot Standby, release candidate?  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
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.

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Nathan Boley
Date:
Subject: Re: Range types
Next
From: Tom Lane
Date:
Subject: Re: Range types