Re: Hot Standby, release candidate?
От | Simon Riggs |
---|---|
Тема | Re: Hot Standby, release candidate? |
Дата | |
Msg-id | 1260825651.1955.2023.camel@ebony обсуждение исходный текст |
Ответ на | Re: Hot Standby, release candidate? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Hot Standby, release candidate?
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: