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: (view raw or whole 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 =

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.



In response to


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-2015 The PostgreSQL Global Development Group