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 по дате отправления:

Предыдущее
От: ITAGAKI Takahiro
Дата:
Сообщение: Re: LWLock statistics collector
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: [PATCHES] Forcing current WAL file to be archived