On 2021/03/26 10:08, Kyotaro Horiguchi wrote:
> At Thu, 25 Mar 2021 19:01:23 +0900, Fujii Masao <masao.fujii@oss.nttdata.com> wrote in
>> On 2021/03/25 16:37, Kyotaro Horiguchi wrote:
>>> pgWalUsage was used without resetting and we (I) thought that that
>>> behavior should be preserved. On second thought, as Andres suggested,
>>> we can just reset pgWalUsage at sending since AFAICS no one takes
>>> difference crossing pgstat_report_stat() calls.
>>
>> Yes, I agree that we can do that since there seems no such code for
>> now.
>> Also if we do that, we can check, for example "pgWalUsage.wal_records
>>> 0"
>> as you suggested, to easily determine whether there is pending WAL
>> stats or not.
>> Anyway I agree it's better to add comments about the design more.
> ...
>>> If any wal activity has been recorded, wal_records is always positive
>>> thus we can check for wal activity just by "pgWalUsage.wal_records >
>>> 0, which should be fast enough.
>>
>> Maybe there is the case where a backend generates no WAL records,
>> but just writes them because it needs to do write-ahead-logging
>> when flush the table data? If yes, "pgWalUsage.wal_records > 0" is not
>> enough.
>> Probably other fields also need to be checked.
>
> (I noticed I made the discussion above unconsciously premising
> pgWalUsage reset.)
>
> I may be misunderstanding or missing something, but the only place
> where pgWalUsage counters are increased is XLogInsertRecrod. That is,
> pgWalUsage counts wal insertions, not writes nor flushes. AFAICS
Yes. And WalStats instead of pgWalUsage includes the stats about
not only WAL insertions, but also writes and flushes.
pgstat_send_wal() checks WalStats to determine whether there are
pending WAL stats to send to the stats collector or not. That is,
the counters of not only WAL insertions but also writes and flushes
should be checked to determine whether there are pending stats or not, I think..
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION