Re: Avoid overflow with simplehash - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Avoid overflow with simplehash
Date
Msg-id 20230706152733.dg3ls5shed4tn4ce@awork3.anarazel.de
Whole thread Raw
In response to Re: Avoid overflow with simplehash  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Avoid overflow with simplehash
List pgsql-hackers
Hi,

On 2023-07-06 11:16:26 -0400, Tom Lane wrote:
> Ranier Vilela <ranier.vf@gmail.com> writes:
> > See the comments:
> > "Search for the first empty element."
> > If the empty element is not found, startelem has PG_UINT64_MAX value,
> > which do not fit in uint32.
> 
> I think the point of that assertion is exactly that we're required to
> have an empty element (because max fillfactor is less than 1),
> so the search should have succeeded.

Right, that part of the proposed change seems bogus to me.


> It does seem like we could do
> 
>     uint64        startelem = SH_MAX_SIZE;
> 
>     ...
> 
>     Assert(startelem < SH_MAX_SIZE);
> 
> which'd make it a little clearer that the expectation is for
> startelem to have changed value.

I guess? I find it easier to understand all-bits-set in a coredump as
too-large than SH_MAX_SIZE, but ...


> And I agree that declaring "i" as int is wrong.

Yea, that's definitely not right, not sure how I ended up with that. Will push
a fix. I guess it should be backpatched...

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] Add GitLab CI to PostgreSQL
Next
From: "Tristan Partin"
Date:
Subject: Re: pg_recvlogical prints bogus error when interrupted