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-13T18:07:27Z
Lists: pgsql-hackers 
On Wed, Mar 13, 2019 at 1:30 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Ah, here we are: it was rel->rd_partcheck.  I'm not sure exactly how
> complicated that structure can be, but I'm pretty sure that this is
> a laughably inadequate method of cleaning it up:
>
>         if (relation->rd_partcheck)
>                 pfree(relation->rd_partcheck);

Oh, for crying out loud.

> Dunno if that's related to hyrax's issue, though.

It's related in the sense that it's a leak, and any leak will tend to
run the system out of memory more easily, but what I observed was a
large leak into MessageContext, and that would be a leak into
CacheMemoryContext, so I think it's probably a sideshow rather than
the main event.

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