On 2017/03/08 22:36, Robert Haas wrote: > On Wed, Mar 8, 2017 at 5:36 AM, Amit Langote wrote: >>> - rel = mtstate->resultRelInfo->ri_RelationDesc; >>> + nominalRTE = rt_fetch(node->nominalRelation, estate->es_range_table); >>> + nominalRel = heap_open(nominalRTE->relid, NoLock); >>> >>> No lock? >> >> Hmm, I think I missed that a partitioned parent table would not be locked >> by the *executor* at all after applying this patch. As of now, InitPlan() >> takes care of locking all the result relations in the >> PlannedStmt.resultRelations list. This patch removes partitioned >> parent(s) from appearing in this list. But that makes me wonder - aren't >> the locks taken by expand_inherited_rtentry() kept long enough? Why does >> InitPlan need to acquire them again? I see this comment in >> expand_inherited_rtentry: > > Parse-time locks, plan-time locks, and execution-time locks are all > separate. See the header comments for AcquireRewriteLocks in > rewriteHandler.c; think about a view, where the parsed query has been > stored and is later rewritten and planned. Similarly, a plan can be > reused even after the transaction that created that plan has > committed; see AcquireExecutorLocks in plancache.c.
Thanks for those references. I took a step back here and thought a bit more about the implications this patch. It occurred to me that the complete absence of partitioned table RT entries in the plan-tree has more consequences than I originally imagined. I will post an updated patch by Monday latest. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
