On Thu, Jan 31, 2019 at 1:02 PM Robert Haas <robertmh...@gmail.com> wrote: > New patch series attached.
And here's yet another new patch series, rebased over today's commit and with a couple of other fixes: 1. I realized that the PartitionDirectory for the planner ought to be attached to the PlannerGlobal, not the PlannerInfo; we don't want to create more than one partition directory per query planning cycle, and we do want our notion of the PartitionDesc for a given relation to be stable between the outer query and any subqueries. 2. I discovered - via CLOBBER_CACHE_ALWAYS testing - that the PartitionDirectory has to hold a reference count on the relcache entry. In hindsight, this should have been obvious: the planner keeps the locks when it closes a relation and later reopens it, but it doesn't keep the relation open, which is what prevents recycling of the old PartitionDesc. Unfortunately these additional reference count manipulations are probably not free. I don't know expensive they are, though; maybe it's not too bad. Aside from these problems, I think I have spotted a subtle problem in 0001. I'll think about that some more and post another update. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
v3-0002-Ensure-that-repeated-PartitionDesc-lookups-return.patch
Description: Binary data
v3-0004-Reduce-the-lock-level-required-to-attach-a-partit.patch
Description: Binary data
v3-0003-Teach-runtime-partition-pruning-to-cope-with-conc.patch
Description: Binary data
v3-0001-Ensure-that-RelationBuildPartitionDesc-sees-a-con.patch
Description: Binary data
