Re: Delay locking partitions during INSERT and UPDATE

David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> On Tue, 19 Feb 2019 at 11:47, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Are we talking about the same patch? The one I'm looking at seems
>> to be mostly planner and plancache changes:

> Looks like you're looking at the patch from the "Delay locking
> partitions during query execution" thread [1]. Different thing
> altogether, although the names are confusingly similar.

My apologies --- I searched my inbox for "Delay locking partitions",
and failed to notice that I was extracting a patch from the wrong
thread with that in its title. (The questions I posed should
be posted to that thread instead, as they still apply there.)

Now that I've looked at *this* thread's patch, I agree that having
the executor acquire locks based on find_all_inheritors() is a
pretty horrid idea. However, it still seems like this is being
done in a vacuum without attention to locks already acquired
upstream. How much does the knowledge that the planner or plancache
would've already locked everything mentioned in the rangetable
affect the issues here?

I'm inclined to think that if we already have lock on the parent
partitioned table (thereby, IIUC, guaranteeing that its partitioning
info can't change) that the order in which we acquire the same lock
level on its partition(s) isn't very important.

regards, tom lane