"Pavan Deolasee" <[EMAIL PROTECTED]> writes: > I traced it a bit and it seems that the invalidation messages > are not accepted in session 2 because the locks are already held > on the relation.
Right, because of this coding in LockRelationOid(): /* * Now that we have the lock, check for invalidation messages, so that we * will update or flush any stale relcache entry before we try to use it. * We can skip this in the not-uncommon case that we already had the same * type of lock being requested, since then no one else could have * modified the relcache entry in an undesirable way. (In the case where * our own xact modifies the rel, the relcache update happens via * CommandCounterIncrement, not here.) */ if (res != LOCKACQUIRE_ALREADY_HELD) AcceptInvalidationMessages(); We could remove the optimization and do AcceptInvalidationMessages always, but I think that cure would be a great deal worse than the disease --- it would hugely increase the contention for SInvalLock. I'm not particularly worried about missing a potential improvement in the plan during the first command after a change is committed. If the invalidation were something that *had* to be accounted for, such as a dropped index, then there should be adequate locking for it; plancache is not introducing any new bug that wasn't there before. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match