Re: bgwriter doesn't flush WAL stats
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: byavuz81@gmail.com
Cc: boekewurm+postgres@gmail.com, pgsql-hackers@postgresql.org
Date: 2023-06-22T01:48:54Z
Lists: pgsql-hackers
At Wed, 21 Jun 2023 18:52:26 +0300, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote in > I attached a WIP patch for showing WAL stats in pg_stat_io. Yeah, your diagnosis appears accurate. I managed to trigger an assertion failure quite easily when I added "Assert(!pgstat_have_pending_wal()) just after the call to pgstat_report_bgwriter(). Good find! I slightly inclined to place the added call after smgrcloseall() but it doesn't seem to cause any io-stats updates so the proposed first patch as-is looks good to me. Regarding the second patch, it introduces WAL IO time as a IOCONTEXT_NORMAL/IOOBJECT_WAL, but it doesn't seem to follow the convention or design of the pgstat_io component, which primarily focuses on shared buffer IOs. There was a brief mention about WAL IO during the development of pgstat_io [1]. >> It'd be different if we tracked WAL fsyncs more granularly - which would be >> quite interesting - but that's something for another day^Wpatch. >> >> > I do have a question about this. > So, if we were to start tracking WAL IO would it fit within this > paradigm to have a new IOPATH_WAL for WAL or would it add a separate > dimension? [1] https://www.postgresql.org/message-id/CAAKRu_bM55pj3pPRW0nd_-paWHLRkOU69r816AeztBBa-N1HLA%40mail.gmail.com regards. -- Kyotaro Horiguchi NTT Open Source Software Center
Commits
-
Flush WAL stats in bgwriter
- 594001864a36 14.10 landed
- 0684d1949fb4 15.5 landed
- 4a97a43a73cb 16.1 landed
- e64c733bb199 17.0 landed