Re: parse_oper cache

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: parse_oper cache
Date: 2009-12-27 17:59:47
Message-ID: 11704.1261936787@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2009-12-27 19:11:26 Re: Small Bug in GetConflictingVirtualXIDs
Previous Message Greg Stark 2009-12-27 16:11:07 Re: Removing pg_migrator limitations