Re: Avoid overflow with simplehash

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Avoid overflow with simplehash
Date: 2023-07-06 15:27:33
Message-ID: 20230706152733.dg3ls5shed4tn4ce@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2023-07-06 11:16:26 -0400, Tom Lane wrote:
> Ranier Vilela <ranier(dot)vf(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tristan Partin 2023-07-06 15:29:10 Re: pg_recvlogical prints bogus error when interrupted
Previous Message Peter Eisentraut 2023-07-06 15:19:13 Re: [PATCH] Add GitLab CI to PostgreSQL