I noticed that the plan invalidation is not immediately effective.
Not sure whether it's worth fixing or has any other side-effects,
but thought would just post it.
I was testing the following scenario:
session1 session2
CREATE TABLE test
(int a, int b);
INSERT INTO TABLE
SET enable_seqscan = off
BEGIN
PREPARE myplan AS SELECT * FROM TEST
WHERE a = 100;
EXPLAIN EXECUTE myplan; (seq scan)
CREATE INDEX
-----> EXPLAIN EXECUTE myplan (seq scan)
EXPLAIN EXECUTE myplan (index scan)
The second "EXPLAIN" in session 2 uses seq scan because the plan
is not invalidated and replanned properly. Ideally it should have
used the index scan.
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. At the end of the command, session 2 calls
CommandCounterIncrement() and gets the invalidation messages.
Hence the next EXPLAIN revalidates the plan properly.
May be this is not such an important issue. But I was wondering
if there are other places in the code where we might miss
or receive invalidation messages with a delay, mostly because
of *lack* of lock conflict ?
Thanks,
Pavan
--
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
