Re: [HACKERS] Another nasty cache problem
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] Another nasty cache problem |
Дата | |
Msg-id | Pine.GSO.4.02A.10001311337440.12762-100000@Hund.DoCS.UU.SE обсуждение исходный текст |
Ответ на | Another nasty cache problem (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Another nasty cache problem
|
Список | pgsql-hackers |
On Sun, 30 Jan 2000, Tom Lane wrote: > There are plenty of routines that do two or more SearchSysCacheTuple > calls to get the information they need. As the code stands, it is > unsafe to continue accessing the tuple returned by SearchSysCacheTuple > after making a second such call, because the second call could possibly > cause an SI cache reset message to be processed, thereby flushing the > contents of the caches. > > heap_open and CommandCounterIncrement are other routines that could > cause cache entries to be dropped. This sort of thing should be documented, at least in the comment on top of the function. From the developer's FAQ I gathered something like that these tuples can be used for a short while, which is of course very exact. Anyway, I just counted 254 uses of SearchSysCacheTuple in the backend tree and a majority of these are probably obviously innocent. Since I don't have any more developing planned, I would volunteer to take a look at all of those and look for violations of second cache look up, heap_open, and CommandCounterIncrement, fixing them where possible, or at least pointing them out to more experienced people. That might save you from going out of your way and instituting some reference count or whatever, and it would be an opportunity for me to read some code. -- Peter Eisentraut Sernanders vaeg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
В списке pgsql-hackers по дате отправления: