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
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 |