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

  Simon Riggs             
  EnterpriseDB   http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to