Re: LWLock statistics collector (was: CSStorm occurred again by postgreSQL8.2) - Mailing list pgsql-hackers

From Katsuhiko Okano
Subject Re: LWLock statistics collector (was: CSStorm occurred again by postgreSQL8.2)
Date
Msg-id 200608042005.CEB00073.PLuVPTOBUILJLBP@oss.ntt.co.jp
Whole thread Raw
In response to Re: LWLock statistics collector (was: CSStorm occurred again by postgreSQL8.2)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: ITAGAKI Takahiro
Date:
Subject: Re: LWLock statistics collector
Next
From: Simon Riggs
Date:
Subject: Re: [PATCHES] Forcing current WAL file to be archived