Horton

Re: hyrax vs. RelationBuildPartitionDesc

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-03-13T18:26:28Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
>> 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.

OK, in that case it's definitely all the temporary data that gets created
that is the problem.  I've not examined your patch in great detail but
it looks plausible for fixing that.

I think that RelationBuildPartitionDesc could use some additional cleanup
or at least better commenting.  In particular, it's neither documented nor
obvious to the naked eye why rel->rd_partdesc mustn't get set till the
very end.  As the complainant, I'm willing to go fix that, but do you want
to push your patch first so it doesn't get broken?  Or I could include
your patch in the cleanup.

			regards, tom lane

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.