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

Re: CLOG contention, part 2

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CLOG contention, part 2
Date: 2012-01-27 22:05:41
Message-ID: CAMkU=1xmSBJxidW-m5kBAcWTBdvR87=rwLj7Ep6Vsnf-1+Q9bg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sat, Jan 21, 2012 at 7:31 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> Yes, it was. Sorry about that. New version attached, retesting while
> you read this.

In my hands I could never get this patch to do anything.  The new
cache was never used.

I think that that was because RecentXminPageno never budged from -1.

I think that that, in turn, is because the comparison below can never
return true, because the comparison is casting both sides to uint, and
-1 cast to uint is very large

        /* When we commit advance ClogCtl's shared RecentXminPageno if needed */
        if (ClogCtl->shared->RecentXminPageno < TransactionIdToPage(RecentXmin))
                 ClogCtl->shared->RecentXminPageno =
TransactionIdToPage(RecentXmin);


Also, I think the general approach is wrong.  The only reason to have
these pages in shared memory is that we can control access to them to
prevent write/write and read/write corruption.  Since these pages are
never written, they don't need to be in shared memory.   Just read
each page into backend-local memory as it is needed, either
palloc/pfree each time or using a single reserved block for the
lifetime of the session.  Let the kernel worry about caching them so
that the above mentioned reads are cheap.

Cheers,

Jeff

In response to

Responses

pgsql-hackers by date

Next:From: hubert depesz lubaczewskiDate: 2012-01-27 22:19:18
Subject: pg_dump -s dumps data?!
Previous:From: Jeff JanesDate: 2012-01-27 21:45:16
Subject: Re: Simulating Clog Contention

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