Skip site navigation (1) Skip section navigation (2)

Re: Plan invalidation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Plan invalidation
Date: 2007-04-03 18:15:52
Message-ID: 10638.1175624152@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
"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)
        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

In response to

Responses

pgsql-hackers by date

Next:From: Pavan DeolaseeDate: 2007-04-03 18:27:56
Subject: Re: Plan invalidation
Previous:From: Heikki LinnakangasDate: 2007-04-03 18:14:24
Subject: Re: notification payloads

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group