| 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-14 08:24:22 | 
| Message-ID: | 3A10F6B6.FF40B0ED@tpf.co.jp | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Tom Lane wrote:
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> 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 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 ?
Is it more serious than forcing database restart ?
We couldn't handle SI messages immediately.
Cache machanism couldn't gurantee the validty of
tuples without some locking mechanism in the first
place.
Regards.
Hiroshi Inoue
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2000-11-14 11:30:00 | why transfer limits on ftp.postgresql.org ? | 
| Previous Message | Tom Lane | 2000-11-14 07:35:44 | Re: SearchSysCacheTuple(Copy) |