Re: Recursive use of syscaches (was: relation ### modified while in use)
От | Hiroshi Inoue |
---|---|
Тема | Re: Recursive use of syscaches (was: relation ### modified while in use) |
Дата | |
Msg-id | 3A0B47C7.100B9F9E@tpf.co.jp обсуждение исходный текст |
Ответ на | RE: relation ### modified while in use ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
Ответы |
Re: Recursive use of syscaches (was: relation ### modified while in use)
|
Список | pgsql-hackers |
Tom Lane wrote: > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > >> Does this occur after a prior error message? I have been suspicious > >> because there isn't a mechanism to clear the syscache-busy flags during > >> xact abort. > > > I don't know if I've seen the cases you pointed out. > > I have the following gdb back trace. Obviously it calls > > SearchSysCache() for cacheId 10 twice. I was able > > to get another gdb back trace but discarded it by > > mistake. Though I've added pause() just after detecting > > recursive use of cache,backends continue the execution > > in most cases unfortunately. > > I've not examined the backtrace yet. But don't we have > > to nail system relation descriptors more than now ? > > I don't think that's the solution; nailing more descriptors than we > absolutely must is not a pretty approach, I don't object to remove the check 'recursive use of cache' because it's not a real check of recursion. My concern is the robustness of rel cache. It seems pretty dangerous to discard system relation descriptors used for cache mechanism especially in case of error recovery. It also seems pretty dangerous to recontruct relation descriptors especially in case of error recovery. Regards. Hiroshi Inoue
В списке pgsql-hackers по дате отправления: