Re: hyrax vs. RelationBuildPartitionDesc

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, Alvaro Herrera <alvherre@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, amul sul <sulamul@gmail.com>
Date: 2019-06-04T12:25:32Z
Lists: pgsql-hackers

Attachments

On Fri, May 17, 2019 at 4:36 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Yeah, I did some additional testing that showed that it's pretty darn
> hard to get the leak to amount to anything.  The test case that I
> originally posted did many DDLs in a single transaction, and it
> seems that that's actually essential to get a meaningful leak; as
> soon as you exit the transaction the leaked contexts will be recovered
> during sinval cleanup.

My colleague Amul Sul rediscovered this same leak when he tried to
attach lots of partitions to an existing partitioned table, all in the
course of a single transaction.  This seems a little less artificial
than Tom's original reproducer, which involved attaching and detaching
the same partition repeatedly.

Here is a patch that tries to fix this, along the lines I previously
suggested; Amul reports that it does work for him.  I am OK to hold
this for v13 if that's what people want, but I think it might be
smarter to commit it to v12.  Maybe it's not a big leak, but it seems
easy enough to do better, so I think we should.

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