Re: Separating bgwriter and checkpointer

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: "Dickson S(dot) Guedes" <listas(at)guedesoft(dot)net>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Separating bgwriter and checkpointer
Date: 2011-10-19 12:45:25
Message-ID: CA+TgmoZXk7=CrAzszvL7K9g4xWjSBbA0Gn2A5XbiJx74zXzA6Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 19, 2011 at 8:43 AM, Dickson S. Guedes <listas(at)guedesoft(dot)net> wrote:
> 2011/10/19 Fujii Masao <masao(dot)fujii(at)gmail(dot)com>:
>> On Tue, Oct 18, 2011 at 10:18 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>> Any reason or objection to committing this patch?
>>
>> The checkpointer doesn't call pgstat_send_bgwriter(), but it should.
>> Otherwise, some entries in pg_stat_bgwriter will never be updated.
>
> Yes, checkpoints_req, checkpoints_timed and buffer_checkpoint are not
> being updated with this patch.
>
>> If we adopt the patch, checkpoint is performed by checkpointer. So
>> it looks odd that information related to checkpoint exist in
>> pg_stat_bgwriter. We should move them to new catalog even if
>> it breaks the compatibility?
>
> Splitting pg_stat_bgwriter into pg_stat_bgwriter and
> pg_stat_checkpointer will break something internal?
>
> With this modification we'll see applications like monitoring tools
> breaking, but they could use a view to put data back together in a
> compatible way, IMHO.

I don't really see any reason to break the monitoring view just
because we did some internal refactoring. I'd rather have backward
compatibility.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kerem Kat 2011-10-19 13:01:09 (PATCH) Adding CORRESPONDING to Set Operations
Previous Message Robert Haas 2011-10-19 12:44:37 Re: loss of transactions in streaming replication