Skip site navigation (1) Skip section navigation (2)

Re: Shared locking in slru.c

From: Manfred Koizar <mkoi-pg(at)aon(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Shared locking in slru.c
Date: 2005-12-02 10:09:41
Message-ID: t870p1d9ooqa3j6juglrv4vvq68gh7ncue@4ax.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, 30 Nov 2005 13:53:13 -0500, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
wrote:
>The way the attached patch attacks this is for the shared-lock access
>case to simply set the page's LRU counter to zero, without bumping up
>the LRU counters of the other pages as the normal adjustment would do.

If you still plan to do this, you might also want to revert the
micro-optimisation intruduced by the original SLRU patch:

| Apart from refactoring I made a little change to SlruRecentlyUsed,
| formerly ClogRecentlyUsed:  It now skips incrementing lru_counts, if
| slotno is already the LRU slot, thus saving a few CPU cycles.

|+#define SlruRecentlyUsed(shared, slotno)	\
|+	do { \
|+		if ((shared)->page_lru_count[slotno] != 0) { \
|+			int		iilru; \
|+			for (iilru = 0; iilru < NUM_CLOG_BUFFERS; iilru++) \
|+				(shared)->page_lru_count[iilru]++; \
|+			(shared)->page_lru_count[slotno] = 0; \
|+		} \
|+	} while (0)

Otherwise you could end up with a stable state of several pages having
lru_count == 0.
Servus
 Manfred


In response to

Responses

pgsql-hackers by date

Next:From: Anuj TripathiDate: 2005-12-02 10:45:55
Subject: Graphics in postgress using GTK
Previous:From: Csaba NagyDate: 2005-12-02 10:07:06
Subject: Re: generalizing the planner knobs

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group