Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sv73z-00CXz0-Vf for pgsql-hackers@arkaria.postgresql.org; Mon, 30 Sep 2024 03:27:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sv73z-00Bejn-8D for pgsql-hackers@arkaria.postgresql.org; Mon, 30 Sep 2024 03:27:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sv73y-00BejY-V4 for pgsql-hackers@lists.postgresql.org; Mon, 30 Sep 2024 03:27:06 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sv73t-001m7n-Mo for pgsql-hackers@lists.postgresql.org; Mon, 30 Sep 2024 03:27:06 +0000 Received: from [192.168.11.3] (p3610184-ipxg13101funabasi.chiba.ocn.ne.jp [60.45.23.184]) by oss.nttdata.com (Postfix) with ESMTPSA id 29A5861A7A; Mon, 30 Sep 2024 12:26:57 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at oss.nttdata.com Message-ID: <2adc5283-ae2c-424a-babf-0247eeebf5a3@oss.nttdata.com> Date: Mon, 30 Sep 2024 12:26:56 +0900 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: May be BUG. Periodic burst growth of the checkpoint_req counter on replica. Content-Language: en-US To: "Anton A. Melnikov" , Alexander Korotkov Cc: Magnus Hagander , "Anton A. Melnikov" , Andres Freund , Kyotaro Horiguchi , pgsql-hackers@lists.postgresql.org References: <99b2ccd1-a77a-962a-0837-191cdf56c2b9@inbox.ru> <7bd1c12b-4219-45bf-88a6-8cacd008dfdc@postgrespro.ru> <3ed0590b-8132-482e-a9e6-bd694e4a48d7@postgrespro.ru> <9ea77f40-818d-4841-9dee-158ac8f6e690@oss.nttdata.com> <77032579-4dc3-4552-9a09-30aaa114c144@postgrespro.ru> <206e58c1-d8f6-4ac3-8f40-7e4c17459473@oss.nttdata.com> <82f03b0b-00c6-42b4-95c7-f2eca7fed1ea@oss.nttdata.com> <4640258e-d959-4cf0-903c-cd02389c3e05@oss.nttdata.com> <8e5f353f-8b31-4a8e-9cfa-c037f22b4aee@postgrespro.ru> From: Fujii Masao In-Reply-To: <8e5f353f-8b31-4a8e-9cfa-c037f22b4aee@postgrespro.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2024/09/22 13:55, Anton A. Melnikov wrote: > On 20.09.2024 19:19, Fujii Masao wrote: >> I've attached the updated version (0001.patch). I made some cosmetic changes, >> including reverting the switch in the entries for pg_stat_get_checkpointer_write_time >> and pg_stat_get_checkpointer_sync_time in pg_proc.dat, as I didn’t think >> that change was necessary. Could you please review the latest version? > > Thanks for corrections! > All looks good for me. Thanks for the review! I've pushed the 0001 patch. > As for switching in the pg_proc.dat entries the idea was to put them in order > so that the pg_stat_get_checkpointer* functions were grouped together. > I don't know if this is the common and accepted practice. Simply i like it better this way. > Sure, if you think it's unnecessary, let it stay as is with minimal diff. I understand your point, but I didn't made that change to keep the diff minimal, which should make future back-patching easier. >> After we commit 0001.patch, how about applying 0002.patch, which updates >> the documentation for the pg_stat_checkpointer view to clarify what types >> of checkpoints and restartpoints each counter tracks? > > I liked that the short definitions of the counters are now separated from > the description of its work features which are combined into one paragraph. > It seems to me that is much more logical and easier to understand. Thanks for the review! > In addition, checkpoints may be skipped due to "checkpoints are occurring > too frequently" error. Not sure, but maybe add this information to > the new description? From what I can see in the code, that error message doesn’t seem to indicate the checkpoint is being skipped. In fact, checkpoints are still happening actually when that message appears. Am I misunderstanding something? >> In 0002.patch, I also modified the description of num_requested from >> "Number of backend requested checkpoints" to remove "backend," as it can >> be confusing since num_requested includes requests from sources other than >> the backend. Thought? > > Agreed. E.g. from xlog. Then maybe changed it also in the function > descriptions in the pg_proc.dat? For pg_stat_get_checkpointer_num_requested() > and pg_stat_get_checkpointer_restartpoints_requested(). Yes, good catch! Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION