Re: May be BUG. Periodic burst growth of the checkpoint_req counter on replica. - Mailing list pgsql-hackers

From Anton A. Melnikov
Subject Re: May be BUG. Periodic burst growth of the checkpoint_req counter on replica.
Date
Msg-id 7bd1c12b-4219-45bf-88a6-8cacd008dfdc@postgrespro.ru
Whole thread Raw
In response to Re: May be BUG. Periodic burst growth of the checkpoint_req counter on replica.  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: May be BUG. Periodic burst growth of the checkpoint_req counter on replica.
List pgsql-hackers
Thanks for remarks!

On 28.11.2023 21:34, Alexander Korotkov wrote:
> After examining the second patch
> ("v2-0001-Add-restartpoint-stats.patch"), it appears that adding
> additional statistics as outlined in the patch is the most suitable
> approach to address the concerns raised. This solution provides more
> visibility into the system's behavior without altering its core
> mechanics.

Agreed. I left only this variant of the patch and rework it due to commit 96f05261.
So the new counters is in the pg_stat_checkpointer view now.
Please see the v3-0001-add-restartpoints-stats.patch attached.


> However, it's essential that this additional functionality
> is accompanied by comprehensive documentation to ensure clear
> understanding and ease of use by the PostgreSQL community.
> 
> Please consider expanding the documentation to include detailed
> explanations of the new statistics and their implications in various
> scenarios.

In the separate v3-0002-doc-for-restartpoints-stats.patch i added the definitions
of the new counters into the "28.2.15. pg_stat_checkpointer" section
and explanation of them with examples into the "30.5.WAL Configuration" one.

Would be glad for any comments and and concerns.

With the best wishes,

-- 
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Attachment

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Syncrep and improving latency due to WAL throttling
Next
From: li jie
Date:
Subject: Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding