"Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com> 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)
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
In response to
pgsql-hackers by date
|Next:||From: Pavan Deolasee||Date: 2007-04-03 18:27:56|
|Subject: Re: Plan invalidation|
|Previous:||From: Heikki Linnakangas||Date: 2007-04-03 18:14:24|
|Subject: Re: notification payloads|