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
