Re: Hot Standby, release candidate?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Hot Standby, release candidate?
Date: 2009-12-14 20:24:21
Message-ID: 13308.1260822261@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-12-14 20:29:12 Re: Range types
Previous Message Nathan Boley 2009-12-14 20:12:48 Re: Range types