Re: wal stats questions

Поиск
Список
Период
Сортировка
От Masahiro Ikeda
Тема Re: wal stats questions
Дата
Msg-id E3774ACD-7894-451E-9F13-71E097D10595@oss.nttdata.com
обсуждение исходный текст
Ответ на wal stats questions  (Andres Freund <andres@anarazel.de>)
Ответы Re: wal stats questions
Re: wal stats questions
Список 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 по дате отправления:

Предыдущее
От: Mark Dilger
Дата:
Сообщение: Re: pg_amcheck contrib application
Следующее
От: "houzj.fnst@fujitsu.com"
Дата:
Сообщение: RE: Parallel INSERT SELECT take 2