Re: [HACKERS] Partitioned tables and relfilenode

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