ImmediateSharedRelationCacheInvalidate considered harmful
От | Tom Lane |
---|---|
Тема | ImmediateSharedRelationCacheInvalidate considered harmful |
Дата | |
Msg-id | 194.949178435@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
RE: ImmediateSharedRelationCacheInvalidate considered harmful
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: