Re: LWLock statistics collector (was: CSStorm occurred again by postgreSQL8.2)
От | Katsuhiko Okano |
---|---|
Тема | Re: LWLock statistics collector (was: CSStorm occurred again by postgreSQL8.2) |
Дата | |
Msg-id | 200608042005.CEB00073.PLuVPTOBUILJLBP@oss.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: LWLock statistics collector (was: CSStorm occurred again by postgreSQL8.2) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > I'm confused ... is this patch being proposed for inclusion? I > understood your previous message to say that it didn't help much. This is only the patch for carving where there is any problem. > The patch is buggy as posted, because it will try to do this: > if (shared->page_status[bestslot] == SLRU_PAGE_CLEAN) > return bestslot; > while bestslot could still be -1. A check is required. understood. > (They > will pick a different buffer, because the guy who got the buffer will > have done SlruRecentlyUsed on it before releasing the control lock --- > so I don't believe the worry that we get a buffer thrash scenario here. > Look at the callers of SlruSelectLRUPage not just the function itself.) umm,I read a code again. > otherwise to initiate I/O on the oldest buffer that isn't > either clean or write-busy, if there is one; Understanding is a difficult point although it is important. -------- Katsuhiko Okano okano katsuhiko _at_ oss ntt co jp
В списке pgsql-hackers по дате отправления: