Hiroshi, I have been looking at the cache invalidation changes you committed
on 10 Jan. Most of them look fine, but I am suspicious of the routine
ImmediateSharedRelationCacheInvalidate, which you added for md.c to
call when it truncates or removes a relation. I believe that this
routine is unnecessary, and since it makes for a very ugly linkage
between md.c and the cache code, I would like to take it out again.
I think it is unnecessary because no backend should ever be deleting
or truncating a relation unless it has an exclusive lock on the
relation. It should be impossible for any other backend to try to
touch the relation until it's acquired some kind of lock on the relation
--- which cannot happen until the deleting/truncating transaction
commits, by which time it will have sent the normal SI message for the
relation's pg_class tuple. And since LockRelation processes SI messages
after acquiring the relation's lock, the other backend should have seen
the SI update before it can do anything with the relation.
Of course, the other backend may have open file descriptors for the
relation's file(s), but so what? The descriptors will get closed when
the SI message is processed, before they can be used for anything; so
the only consequence is that the Unix kernel won't release the physical
file storage until then.
Furthermore, if it *were* necessary to force other backends to react
immediately to md.c's truncation or deletion, the SI message mechanism
will not do the trick, even if a message is sent instantly; there is
no guarantee that other backends will process it promptly.
So I can see no value in this code. Have I missed something?
regards, tom lane