Hi, On 2021-04-23 09:26:17 +0900, Masahiro Ikeda wrote: > On 2021/04/23 0:36, Andres Freund wrote: > > On Thu, Apr 22, 2021, at 06:42, Fujii Masao wrote: > >> On 2021/04/21 18:31, Masahiro Ikeda wrote: > >>>> BTW, is it better to change PgStat_Counter from int64 to uint64 because> > >>>> there aren't any counters with negative number? > >> On second thought, it's ok even if the counters like wal_records get > >> overflowed. > >> Because they are always used to calculate the diff between the previous and > >> current counters. Even when the current counters are overflowed and > >> the previous ones are not, WalUsageAccumDiff() seems to return the right > >> diff of them. If this understanding is right, I'd withdraw my comment and > >> it's ok to use "long" type for those counters. Thought? > > > > Why long? It's of a platform dependent size, which doesn't seem useful here? > > I think it's ok to unify uint64. Although it's better to use small size for > cache, the idea works well for only some platform which use 4bytes for "long". > > > (Although I'm not familiar with the standardization...) > It seems that we need to adopt unsinged long if use "long", which may be > 4bytes. > > I though WalUsageAccumDiff() seems to return the right value too. But, I > researched deeply and found that ISO/IEC 9899:1999 defines unsinged integer > never overflow(2.6.5 Types 9th section) although it doesn't define overflow of > signed integer type. > > If my understanding is right, the definition only guarantee > WalUsageAccumDiff() returns the right value only if the type is unsigned > integer. So, it's safe to change "long" to "unsigned long".
I think this should just use 64bit counters. Emitting more than 4 billion records in one transaction isn't actually particularly rare. And obviously WalUsageAccumDiff() can't do anything about that, once overflowed it overflowed. Greetings, Andres Freund
