On 2015-10-12 08:07:54 +0000, Albe Laurenz wrote:
> Victor Blomqvist wrote:
> [race condition causes errors due to stale plans immediately after ALTER TABLE DROP]
> > Note that these errors most of the time only happens very briefly at the same time as the ALTER is
> > run. When I did some experiments today the server in total had around 3k req/s with maybe 0.1% of them
> > touching the table being updated, and the error then happens maybe 1-10% of the times I try this
> > operation. If I do the operation on a table with more load the error will happen more frequently.
>
> As far as I gleaned from reading the source, plan cache invalidation happens by signals
> sent to the other backends, so I can see why there can be small delays.
> I wonder if there is any good way to improve this.
The signal based part is only relevant for idle backends, to wake them
up to process pending invalidations. The aim is to shrink the size of
the invalidation queue.
Normal invalidations are performed whenever a relation is locked:
void
LockRelationOid(Oid relid, LOCKMODE lockmode)
{
LOCKTAG tag;
LockAcquireResult res;
SetLocktagRelationOid(&tag, relid);
res = LockAcquire(&tag, lockmode, false, false);
/*
* 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.
* RangeVarGetRelid() specifically relies on us for this. 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();
}
I've not investigated what the OP's problem is.
Greetings,
Andres Freund
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
