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

Re: CLOG contention, part 2

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CLOG contention, part 2
Date: 2012-01-20 15:08:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Jan 20, 2012 at 9:44 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Fri, Jan 20, 2012 at 1:37 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Sun, Jan 8, 2012 at 9:25 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>> I've taken that idea and used it to build a second Clog cache, known
>>> as ClogHistory which allows access to the read-only tail of pages in
>>> the clog. Once a page has been written to for the last time, it will
>>> be accessed via the ClogHistory Slru in preference to the normal Clog
>>> Slru. This separates historical accesses by readers from current write
>>> access by committers. Historical access doesn't force dirty writes,
>>> nor are commits made to wait when historical access occurs.
>> This seems to need a rebase.
> OT: It would save lots of time if we had 2 things for the CF app:
> 1. Emails that go to appropriate people when status changes. e.g. when
> someone sets "Waiting for Author" the author gets an email so they
> know the reviewer is expecting something. No knowing that wastes lots
> of days, so if we want to do this in less days that seems like a great
> place to start.
> 2. Something that automatically tests patches. If you submit a patch
> we run up a blank VM and run patch applies on all patches. As soon as
> we get a fail, an email goes to patch author. That way authors know as
> soon as a recent commit invalidates something.
> Those things have wasted time for me in the past, so they're
> opportunities to improve the process, not must haves.

Yeah, I agree that that would be nice.  I just haven't had time to
implement much of anything for the CF application in a long time.  My
management has been very interested in the performance and scalability
stuff, so that's been my main focus for 9.2.  I'm going to see if I
can carve out some time for this once the dust settles.

Robert Haas
The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2012-01-20 15:16:42
Subject: Re: CLOG contention, part 2
Previous:From: Robert HaasDate: 2012-01-20 15:03:53
Subject: Re: Command Triggers

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