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
