Re: Delay locking partitions during query execution

On Sat, 2 Feb 2019 at 13:43, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>
> On 2/1/19 2:51 PM, Robert Haas wrote:
> >> (I admit to not having the best grasp on how all this works, so feel
> >> free to shoot this down)
> >>
> > I think the key question here is whether or not you can cope with
> > someone having done arbitrary AEL-requiring modifications to the
> > delaylocked partitions. If you can, the fact that the plan might
> > sometimes be out-of-date is an inevitable consequence of doing this at
> > all, but I think we can argue that it's an acceptable consequence as
> > long as the resulting behavior is not too bletcherous. If you can't,
> > then this patch is dead.
>
> I'm a bit confused - does the patch actually change anything here? As
> demonstrated earlier in this thread, it actually behaves just like
> master. No?

I guess Robert meant if it say, failed to execute a cached plan with
say "unable to open relation ..." after someone concurrently did
something like ALTER TABLE ... SET TABLESPACE on one of the
partitions.

This particular case can't happen with the patch since we always
accept invalidation message after we obtain a new lock, but I'm
working through various scenarios just in case there is something that
could invalidate the plan, rather than just the relcache entry.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services