Re: Signed vs. Unsigned (some) - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: Signed vs. Unsigned (some)
Date
Msg-id CAEudQAprLL3LMYp7vh=-9dV2goXQtD5fmd8kc+7Zwqm3p_vYFQ@mail.gmail.com
Whole thread Raw
In response to Re: Signed vs. Unsigned (some)  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
Em sex., 2 de jul. de 2021 às 07:09, Peter Eisentraut <peter.eisentraut@enterprisedb.com> escreveu:
On 16.06.21 10:48, Peter Eisentraut wrote:
> On 15.06.21 10:17, Kyotaro Horiguchi wrote:
>> The definitions are not ((type) -1) but ((type) 0xFFFFFFFF) so
>> actually they might be different if we forget to widen the constant
>> when widening the types.  Regarding to the compiler behavior, I think
>> we are assuming C99[1] and C99 defines that -1 is converted to
>> Uxxx_MAX. (6.3.1.3 Singed and unsigned integers)
>>
>> I'm +0.2 on it.  It might be worthwhile as a matter of style.
>
> I think since we have the constants we should use them.

I have pushed the InvalidBucket changes.
Nice. Thanks.


The use of InvalidBlockNumber with vac_update_relstats() looks a bit
fishy to me.  We are using in the same call 0 as the default for
num_all_visible_pages, and we generally elsewhere also use 0 as the
starting value for relpages, so it's not clear to me why it should be -1
or InvalidBlockNumber here.
It seems to me that the only use in vac_update_relstats is to mark relpages as invalid (dirty = true).
 
  I'd rather leave it "slightly wrong" for
now so it can be checked again.
Ideally InvalidBlockNumber should be 0.
Maybe in the long run this will be fixed.

regards,
Ranier Vilela

pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: Numeric multiplication overflow errors
Next
From: Pavel Stehule
Date:
Subject: Re: Schema variables - new implementation for Postgres 15