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: Re: Recursive use of syscaches (was: relation ### modified while in use) |
Date: | 2000-11-10 01:33:21 |
Message-ID: | 3A0B5061.53D60701@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:
> > My concern is the robustness of rel cache.
> > It seems pretty dangerous to discard system relation
> > descriptors used for cache mechanism especially in
> > case of error recovery.
> > It also seems pretty dangerous to recontruct relation
> > descriptors especially in case of error recovery.
>
> Why? We are able to construct all the non-nailed relcache entries
> from scratch during backend startup. That seems a sufficient
> proof that we can reconstruct any or all of them on demand.
>
Hmm,why is it sufficent ?
At backend startup there are no rel cache except
some nailed rels. When 'reset system cache' message
arrives,there would be many rel cache entries and
some of them may be in use.
In addtion there could be some inconsitency of db
in the middle of the transaction. Is it safe to recon
struct rel cache under the inconsistency ?
Regards.
Hiroshi Inoue
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-11-10 01:45:27 | Re: 7.0.2 dies when connection dropped mid-transaction |
Previous Message | Kevin O'Gorman | 2000-11-10 01:24:25 | Tip of current tree: Seg fault in query |