Re: wal stats questions - Mailing list pgsql-hackers

From Masahiro Ikeda
Subject Re: wal stats questions
Date
Msg-id E3774ACD-7894-451E-9F13-71E097D10595@oss.nttdata.com
Whole thread Raw
In response to wal stats questions  (Andres Freund <andres@anarazel.de>)
Responses Re: wal stats questions  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Re: wal stats questions  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers


On 2021/04/23 0:36, Andres Freund wrote:
> Hi
>
> 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".

Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION




pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: pg_amcheck contrib application
Next
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: Parallel INSERT SELECT take 2