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)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Recursive use of syscaches (was: relation ### modified while in use)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Recursive use of syscaches (was: relation ### modified while in use)