Re: LWLock statistics collector (was: CSStorm occurred again by postgreSQL8.2)

From: Katsuhiko Okano <okano(dot)katsuhiko(at)oss(dot)ntt(dot)co(dot)jp>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: LWLock statistics collector (was: CSStorm occurred again by postgreSQL8.2)
Date: 2006-08-04 11:05:43
Message-ID: 200608042005.CEB00073.PLuVPTOBUILJLBP@oss.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2006-08-04 11:12:36 Re: [PATCHES] Forcing current WAL file to be archived
Previous Message ITAGAKI Takahiro 2006-08-04 09:57:54 Re: LWLock statistics collector

Browse pgsql-patches by date

  From Date Subject
Next Message Simon Riggs 2006-08-04 11:12:36 Re: [PATCHES] Forcing current WAL file to be archived
Previous Message ITAGAKI Takahiro 2006-08-04 09:57:54 Re: LWLock statistics collector