From: | Zhihong Yu <zyu(at)yugabyte(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Use pg_nextpower2_* in a few more places |
Date: | 2021-06-12 14:44:18 |
Message-ID: | CALNJ-vTVFvKw0M-aMTaMmwY59amWG9ukZDqKmQDYVJZOfrysBg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jun 12, 2021 at 7:35 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> On Sun, 13 Jun 2021 at 02:08, Zhihong Yu <zyu(at)yugabyte(dot)com> wrote:
> > Maybe add an assertion after the assignment, that newalloc >=
> LWLockTrancheNamesAllocated.
>
> I don't quite see how it would be possible for that to ever fail. I
> could understand adding an Assert() if some logic was outside the
> function and we wanted to catch something outside of the function's
> control, but that's not the case here. All the logic is within a few
> lines.
>
> Maybe it would help if we look at the if condition that this code
> executes under:
>
> /* If necessary, create or enlarge array. */
> if (tranche_id >= LWLockTrancheNamesAllocated)
>
> So since we're doing:
>
> + newalloc = pg_nextpower2_32(Max(8, tranche_id + 1));
>
> assuming pg_nextpower2_32 does not give us something incorrect, then I
> don't quite see why Assert(newalloc >= LWLockTrancheNamesAllocated)
> could ever fail.
>
> Can you explain why you think it might?
>
> David
>
Hi,
Interesting, the quoted if () line was not shown in the patch.
Pardon my not checking this line.
In that case, the assertion is not needed.
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2021-06-12 15:07:18 | Add proper planner support for ORDER BY / DISTINCT aggregates |
Previous Message | David Rowley | 2021-06-12 14:35:08 | Re: Use pg_nextpower2_* in a few more places |