Horton

Re: hyrax vs. RelationBuildPartitionDesc

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-03-13T20:50:53Z
Lists: pgsql-hackers 
On Wed, Mar 13, 2019 at 4:38 PM Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Mar 13, 2019 at 4:18 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Off topic for the moment, since this clearly wouldn't be back-patch
> > material, but I'm starting to wonder if we should just have a context
> > for each relcache entry and get rid of most or all of the retail
> > cleanup logic in RelationDestroyRelation ...
>
> I think that idea might have a lot of merit, but I haven't studied it closely.

It just occurred to me that one advantage of this would be that you
could see how much memory was being used by each relcache entry using
MemoryContextStats(), which seems super-appealing.  In fact, what
about getting rid of all allocations in CacheMemoryContext itself in
favor of some more specific context in each case?  That would make it
a lot clearer where to look for leaks -- or efficiencies.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Load relcache entries' partitioning data on-demand, not immediately.

  2. Prevent memory leaks associated with relcache rd_partcheck structures.

  3. Don't copy PartitionBoundInfo in set_relation_partition_info.

  4. Further reduce memory footprint of CLOBBER_CACHE_ALWAYS testing.

  5. Fix some oversights in commit 2455ab488.

  6. Defend against leaks into RelationBuildPartitionDesc.

  7. Allow ATTACH PARTITION with only ShareUpdateExclusiveLock.