Re: SearchSysCacheTuple(Copy) - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject Re: SearchSysCacheTuple(Copy)
Date
Msg-id 3A11D298.D53FFD6F@tpf.co.jp
Whole thread Raw
In response to SearchSysCacheTuple(Copy)  (Hiroshi Inoue <Inoue@tpf.co.jp>)
List pgsql-hackers
Tom Lane wrote:

> Hiroshi Inoue <Inoue@tpf.co.jp> 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 know if we have a problem
> >> or not.
>
> > Is it more serious than doing the wrong thing silently ?
>
> It'd still be doing the wrong thing silently, in my opinion.
>
> This class of bugs has been there since the beginning of Postgres,
> so I do not feel that we need to panic about it.

Not only SI overflow but also relation invalidatation necessarily
resets catalog cache.
I'm suspicious that the bugs caused by this fragility are rare.
For example I doubt that abnormal block numbers are due
to this bug. If so we could hardly reproduce the error and
it's only the waste of time to investigate the cause.
It would be really serious if the broken tuples are stored
into database.

Regards.
Hiroshi Inoue



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Re: UUNET socket-file-location patch
Next
From: Tatsuo Ishii
Date:
Subject: Re: can't insert "³\" as varchar in 7.0.2 and 7.1