Re: Re: Recursive use of syscaches (was: relation ### modified while in use)
От | Tom Lane |
---|---|
Тема | Re: Re: Recursive use of syscaches (was: relation ### modified while in use) |
Дата | |
Msg-id | 3030.973824186@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: Recursive use of syscaches (was: relation ### modified while in use) (Hiroshi Inoue <Inoue@tpf.co.jp>) |
Список | pgsql-hackers |
Hiroshi Inoue <Inoue@tpf.co.jp> writes: > Tom Lane wrote: >> 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. Doesn't bother me. The ones that are in use will get rebuilt. That might trigger recursive rebuilding of system-table relcache entries, and consequently recursive syscache lookups, but so what? That already happens during backend startup: some relcache entries are loaded as a byproduct of attempts to build other ones. > 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 ? No worse than trying to start up while other transactions are running. We don't support on-the-fly modification of schemas for system catalogs anyway, so I don't see the issue. regards, tom lane
В списке pgsql-hackers по дате отправления: