Re: SearchSysCacheTuple(Copy)

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SearchSysCacheTuple(Copy)
Date: 2000-11-15 00:02:32
Message-ID: 3A11D298.D53FFD6F@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:

> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2000-11-15 00:59:48 Re: can't insert "³\" as varchar in 7.0.2 and 7.1
Previous Message Bruce Momjian 2000-11-14 23:54:35 Re: Re: UUNET socket-file-location patch