> 4. SearchSysCacheTupleCopy() goes away, since we may as well use
>SearchSysCacheTuple() and ReleaseSysCache() instead of
>SearchSysCacheTupleCopy() and heap_freetuple().
Agreed. The rest sounds good too.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PR
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
>> Callers that want to be certain they have a completely-up-to-date copy
>> should acquire a suitable lock on the associated system relation before
>> calling SearchSysCache().
> I'm suspcious if it's practical.
> What is a suitable lock ?
> The lock sho
Tom Lane wrote:
> I said:
> > This class of bugs has been there since the beginning of Postgres,
> > so I do not feel that we need to panic about it. Let's take the
> > time to design and implement a proper solution, rather than expending
> > effort on a stopgap solution that'll have to be undone
Tom Lane wrote:
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> >> A more serious objection to SearchSysCacheTupleCopy is that once the
> >> tuple is copied out of the syscache, there isn't any mechanism to
> >> detect whether it's still valid. If an SI message arrives for a
> >> recently-copied tu
I said:
> This class of bugs has been there since the beginning of Postgres,
> so I do not feel that we need to panic about it. Let's take the
> time to design and implement a proper solution, rather than expending
> effort on a stopgap solution that'll have to be undone later.
I've reviewed the
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
>> A more serious objection to SearchSysCacheTupleCopy is that once the
>> tuple is copied out of the syscache, there isn't any mechanism to
>> detect whether it's still valid. If an SI message arrives for a
>> recently-copied tuple, we have no way to kno
Tom Lane wrote:
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Isn't it practical to replace all susipicious Search
> > SysCacheTuple() by SearchSysCacheTupleCopy() ?
>
> That would replace a rare failure condition by a not-at-all-rare
> memory leak. I'm not sure there'd be a net gain in reliabi
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Isn't it practical to replace all susipicious Search
> SysCacheTuple() by SearchSysCacheTupleCopy() ?
That would replace a rare failure condition by a not-at-all-rare
memory leak. I'm not sure there'd be a net gain in reliability :-(
A more serious ob
Tom Lane wrote:
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I fixed a few bugs caused by SearchSysCacheTuple()
> > recently. There seems to remain more similar bugs.
>
> Yes, I'm sure there are a lot :-(. We have talked about solving this
> by using some form of reference-counting in the cach
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> I fixed a few bugs caused by SearchSysCacheTuple()
> recently. There seems to remain more similar bugs.
Yes, I'm sure there are a lot :-(. We have talked about solving this
by using some form of reference-counting in the cache, but I don't
believe anyo
Hi
I fixed a few bugs caused by SearchSysCacheTuple()
recently. There seems to remain more similar bugs.
They are ill-natured and so we seem to have to
avoid such bugs by some means. The simplest way is
to call SearchSysCacheTupleCopy() instead of Search
SysCacheTuple(). I've thought another (deb
11 matches
Mail list logo
