Re: CLOG contention, part 2 - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: CLOG contention, part 2
Date
Msg-id CA+U5nMKESrL_XRuEaXvT_84iwVFmE9hfG7jXG8bUebkpAeYttg@mail.gmail.com
Whole thread Raw
In response to Re: CLOG contention, part 2  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: CLOG contention, part 2  (Robert Haas <robertmhaas@gmail.com>)
Re: CLOG contention, part 2  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On Fri, Jan 20, 2012 at 1:37 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sun, Jan 8, 2012 at 9:25 AM, Simon Riggs <simon@2ndquadrant.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.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Marko Kreen
Date:
Subject: Re: Speed dblink using alternate libpq tuple storage
Next
From: Robert Haas
Date:
Subject: Re: our buffer replacement strategy is kind of lame