Re: CLOG contention, part 2

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: CLOG contention, part 2
Дата
Msg-id CA+U5nMKESrL_XRuEaXvT_84iwVFmE9hfG7jXG8bUebkpAeYttg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: CLOG contention, part 2  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: CLOG contention, part 2  (Robert Haas <robertmhaas@gmail.com>)
Re: CLOG contention, part 2  (Jeff Janes <jeff.janes@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Marko Kreen
Дата:
Сообщение: Re: Speed dblink using alternate libpq tuple storage
Следующее
От: Robert Haas
Дата:
Сообщение: Re: our buffer replacement strategy is kind of lame