Re: parse_oper cache

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: parse_oper cache
Дата
Msg-id 11704.1261936787@sss.pgh.pa.us
обсуждение исходный текст
Ответ на parse_oper cache  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: parse_oper cache  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> I was just taking a look at find_oper_cache_entry() and noticed
> something odd.  When we discover that OprCacheHash == NULL, we make
> sure that CacheMemoryContext is initialized before calling
> hash_create().  But since we don't pass HASH_CONTEXT to hash_create(),
> ISTM it's going to use TopMemoryContext anyhow.  utils/mmgr/README
> indicates that the two contexts are basically equivalent anyway so I
> don't think there's any visible breakage as a result of this, but it
> sort of looks like an oversight.

Hmm.  Now that I look, I find half a dozen other places where a caller
of hash_create first calls CreateCacheMemoryContext but then doesn't
do anything with the context.  Some of them are very old code, like
relcache.c, and I'm sure the parse_oper case was copied from someplace
else rather than being coded from scratch.  I wonder whether this is
a leftover of a time when hash_create had a different default for where
to put hash tables.  Too lazy to dig in the CVS history to confirm that
thought though.

My inclination is to leave the actual memory allocation behavior alone
and just get rid of the CreateCacheMemoryContext calls in these places.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Removing pg_migrator limitations
Следующее
От: Andres Freund
Дата:
Сообщение: Small locking bugs in hs