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
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 |