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
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 |