Re: hyrax vs. RelationBuildPartitionDesc

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Alvaro Herrera <alvherre@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-04-10T06:42:20Z
Lists: pgsql-hackers
On Mon, Apr 08, 2019 at 10:40:41AM -0400, Robert Haas wrote:
> On Mon, Apr 8, 2019 at 9:59 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
>> Yeah, it's an open issue IMO.  I think we've been focusing on getting
>> as many feature patches done as we could during the CF, but now it's
>> time to start mopping up problems like this one.

Please note that it is registered as an older bug and not an open
item.

> Do you have any further thoughts based on my last response?

So your last response is that:
https://www.postgresql.org/message-id/CA+Tgmoa5rT+ZR+Vv+q1XLwQtDMCqkNL6B4PjR4V6YAC9K_LBxw@mail.gmail.com
And what are you proposing as patch?  Perhaps something among those
lines?
https://www.postgresql.org/message-id/036852f2-ba7f-7a1f-21c6-00bc3515eda3@lab.ntt.co.jp

> Does anyone else wish to offer opinions?

It seems to me that Tom's argument to push in the way relcache
information is handled by copying its contents sounds sensible to me.
That's not perfect, but it is consistent with what exists (note
PublicationActions for a rather-still-not-much-complex example of
structure which gets copied from the relcache).
--
Michael

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.