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: Amit Langote <amitlangote09@gmail.com>, 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-11T17:57:16Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Jun 6, 2019 at 2:48 AM Amit Langote <amitlangote09@gmail.com> wrote:
>> Attached is a patch that applies on top of Robert's pdoldcxt-v1.patch,
>> which seems to fix this issue for me.

> Yeah, that looks right.  I think my patch was full of fuzzy thinking
> and inadequate testing; thanks for checking it over and coming up with
> the right solution.

> Anyone else want to look/comment?

I think the existing code is horribly ugly and this is even worse.
It adds cycles to RelationDecrementReferenceCount which is a hotspot
that has no business dealing with this; the invariants are unclear;
and there's no strong reason to think there aren't still cases where
we accumulate lots of copies of old partition descriptors during a
sequence of operations.  Basically you're just doubling down on a
wrong design.

As I said upthread, my current inclination is to do nothing in this
area for v12 and then try to replace the whole thing with proper
reference counting in v13.  I think the cases where we have a major
leak are corner-case-ish enough that we can leave it as-is for one
release.

			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.