Re: Recovering from detoast-related catcache invalidations

Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> CatalogCacheCreateEntry() can accept catcache invalidations when it
> opens the toast table, and it now has recheck logic to detect the case
> that the tuple it's processing (ntp) is invalidated. However, isn't it
> also possible that it accepts an invalidation message for a tuple that
> we had processed in an earlier iteration of the loop? Or that a new
> catalog tuple was inserted that should be part of the list we're building?

The expectation is that the list will be built and returned to the
caller, but it's already marked as stale so it will be rebuilt
on next request.

We could consider putting a loop around that, but (a) it might loop a
lot of times, and (b) returning a stale list isn't much different from
the situation where the list-invalidating event arrives a nanosecond
after we finish rather than a nanosecond before. Ultimately it's the
caller's responsibility that the returned list be consistent enough
for its purposes. It might achieve that by first taking a lock on a
related table, for example.

regards, tom lane