RE: ImmediateSharedRelationCacheInvalidate considered harmful
От | Hiroshi Inoue |
---|---|
Тема | RE: ImmediateSharedRelationCacheInvalidate considered harmful |
Дата | |
Msg-id | NDBBIJLOILGIKBGDINDFIEIECCAA.Inoue@tpf.co.jp обсуждение исходный текст |
Ответ на | ImmediateSharedRelationCacheInvalidate considered harmful (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ImmediateSharedRelationCacheInvalidate considered harmful
|
Список | pgsql-hackers |
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > 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'm happy you have noticed it. The call is for abort/crash after mdunlink()/mdtruncate(). mdunlink()/mdtruncate() is executed immediately but SI registration for all backends isn't executed until commit. Yes the call is ugly and it doesn't solve the flaw basically. Transaction control of relation files' handling would solve it basically. Though I have hesitated to add the call,after all I added it because it may be brought to developers' notice. I don't mind to take it out BTW strictly speaking,even a possibilty exists that backends fail between RecordTransactionCommit() and AtCommit_Cache() in CommitTransaction(). This isn't so little a problem if we want a really strict consistency but seems very hard to solve. Regards. Hiroshi Inoue Inoue@tpf.co.jp
В списке pgsql-hackers по дате отправления: