Re: Recursive use of syscaches (was: relation ### modified while in use) - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject Re: Recursive use of syscaches (was: relation ### modified while in use)
Date
Msg-id 3A0B47C7.100B9F9E@tpf.co.jp
Whole thread Raw
In response to RE: relation ### modified while in use  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Responses Re: Recursive use of syscaches (was: relation ### modified while in use)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Recursive use of syscaches (was: relation ### modified while in use)
Next
From: Tom Lane
Date:
Subject: Re: Recursive use of syscaches (was: relation ### modified while in use)