Re: Delay locking partitions during query execution

On Sun, Jan 27, 2019 at 8:26 PM David Rowley
<david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> One way around this would be to always perform an invalidation on the
> partition's parent when performing a relcache invalidation on the
> partition. We could perhaps invalidate all the way up to the top
> level partitioned table, that way we could just obtain a lock on the
> target partitioned table during AcquireExecutorLocks(). I'm currently
> only setting the delaylock flag to false for leaf partitions only.

Would this problem go away if we adopted the proposal discussed in
http://postgr.es/m/24823.1544220272@sss.pgh.pa.us and, if so, is that
a good fix?

I don't quite understand why this is happening. It seems like as long
as you take at least one new lock, you'll process *every* pending
invalidation message, and that should trigger replanning as long as
the dependencies are correct. But maybe the issue is that you hold
all the other locks you need already, and the lock on the partition at
issue is only acquired during execution, at which point it's too late
to replan. If so, then I think something along the lines of the above
might make a lot of sense.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company