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: Amit Langote <amitlangote09@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-04-13T16:13:20Z
Lists: pgsql-hackers 
Amit Langote <amitlangote09@gmail.com> writes:
> To save you the pain of finding the right files to patch in
> back-branches, I made those (attached).

BTW, as far as that goes: I'm of the opinion that the partitioning logic's
factorization in this area is pretty awful, and v12 has made it worse not
better.  It's important IMO that there be a clear distinction between code
that belongs to/can manipulate the relcache, and outside code that ought
at most to examine it (and maybe not even that, depending on where we come
down on this copy-vs-refcount business).  Maybe allowing
utils/cache/partcache.c to be effectively halfway inside the relcache
module is tolerable, but I don't think it's great design.  Allowing
files over in partitioning/ to also have functions inside that boundary
is really not good, especially when you can't even say that all of
partdesc.c is part of relcache.

I"m seriously inclined to put RelationBuildPartitionDesc back where
it was in v11.

			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.