On Fri, Dec 21, 2018 at 6:06 PM David Rowley
<david.rowley@2ndquadrant.com> wrote:
> > I didn't handle that. If partition pruning relies on nothing changing
> > between planning and execution, isn't that broken regardless of any of
> > this? It's true that with the simple query protocol we'll hold locks
> > continuously from planning into execution, and therefore with the
> > current locking regime we couldn't really have a problem. But unless
> > I'm confused, with the extended query protocol it's quite possible to
> > generate a plan, release locks, and then reacquire locks at execution
> > time. Unless we have some guarantee that a new plan will always be
> > generated if any DDL has happened in the middle, I think we've got
> > trouble, and I don't think that is guaranteed in all cases.
>
> Today the plan would be invalidated if a partition was ATTACHED or
> DETACHED. The newly built plan would get the updated list of
> partitions.
I think you're right, and that won't be true any more once we lower
the lock level, so it has to be handled somehow. The entire plan
invalidation mechanism seems to depend fundamentally on
AccessExclusiveLock being used everywhere, so this is likely to be an
ongoing issue every time we want to reduce a lock level anywhere. I
wonder if there is any kind of systematic fix or if we are just going
to have to keep inventing ad-hoc solutions.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company