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