On Mon, 28 Jan 2019 at 20:45, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> It seems to me that plancache.c doesn't really need to perform
> AcquireExecutorLocks()/LockRelationOid() to learn that a partition's
> reloptions property has changed to discard a generic plan and build a new
> one. AFAICT, PlanCacheRelCallback() takes care of resetting a cached plan
> by observing that an invalidation message that it received either from
> the same session or from another session belongs to one of the relations
> in PlannedStmt.relationOids. That list must already contain all
> partitions' OIDs.
Really? So when you tried my case you properly got a plan with a
non-parallel Seq Scan on listp1?
I imagine you didn't with yours since we check for relcache
invalidations at the start of a transaction. I performed both my
EXECUTEs in the same transaction.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
