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
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 |