At Wed, 21 Jun 2023 18:52:26 +0300, Nazir Bilal Yavuz <byavu...@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