On Fri, 2007-03-30 at 11:44 +0530, Pavan Deolasee wrote: > ISTM that the run-another-transaction-afterwards idea would have same > problem with plan invalidation. When the second transaction commits, > the relcache invalidation event is generated. The event may get > consumed > by other backends, but the index may still not be usable to them > because > their xid < xcreat. If no more relcache invalidation events are > generated > after that, the backends would continue to use the cached plan, even > if index becomes usable to them later.
Sounds like we need to allow create index invalidation events to be processed at the the end of the current transaction in the *receiving* backend. That way we don't need to do the run-another-transaction thing and seems a helluva lot cleaner way of doing this. Messages of SHAREDINVALRELCACHE_ID, would be augmented by a boolean deferred flag on the SharedInvalRelcacheMsg struct. Received messages would be stored in a third kind of InvalidationList, then processed during AtEOXact_Inval() whether the receiving transaction commits or not. (see src/backend/utils/cache/inval.c) Not sure how we'd know to *send* the message marked as deferred, but seems like we can work that out also. That seems to allow CCI to not have to wait until the end of time either. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
