Re: CLOG contention, part 2

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CLOG contention, part 2
Date: 2012-01-20 14:44:21
Message-ID: CA+U5nMKESrL_XRuEaXvT_84iwVFmE9hfG7jXG8bUebkpAeYttg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Kreen 2012-01-20 14:49:45 Re: Speed dblink using alternate libpq tuple storage
Previous Message Robert Haas 2012-01-20 14:37:54 Re: Inline Extension