I 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.
> ...
> I'm not totally happy with this heuristic, though, and was
> wond
Manfred Koizar <[EMAIL PROTECTED]> writes:
> On Wed, 30 Nov 2005 13:53:13 -0500, Tom Lane <[EMAIL PROTECTED]>
> 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 p
On Wed, 30 Nov 2005 13:53:13 -0500, Tom Lane <[EMAIL PROTECTED]>
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
On Wed, Nov 30, 2005 at 01:53:13PM -0500, Tom Lane wrote:
> I've been looking at various ways to resolve this, but one thing that
> seems promising is to hack slru.c to take the control lock in shared
> mode, not exclusive mode, for read-only accesses to pages that are
> already in memory. The vas
On Wed, Nov 30, 2005 at 03:23:55PM -0500, Tom Lane wrote:
> Kenneth Marshall <[EMAIL PROTECTED]> writes:
> > ... In pseudo-code, the operations to
> > read the control information are:
>
> > WriteControl:
> > 1. Set latch.
> > 2. Update control information
> > 3. Increment latch version number.
>
I've been fooling around with a test case Rob Creager sent me, which is
able to drive PG into a context-switch storm caused by contention for
the SubtransControlLock. Rob asked for the test case not to be posted
publicly (it's part of some proprietary code), but I found that you can
cause some of
