Re: CLOG contention, part 2
Jeff Janes <jeff.janes@gmail.com>
From: Jeff Janes <jeff.janes@gmail.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2012-01-27T22:05:41Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Call check_keywords.pl in maintainer-check
- 9bf8603c7a91 9.2.0 cited
-
Make the number of CLOG buffers adaptive, based on shared_buffers.
- 33aaa139e630 9.2.0 cited
On Sat, Jan 21, 2012 at 7:31 AM, Simon Riggs <simon@2ndquadrant.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