Re: Use pg_nextpower2_* in a few more places

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.

In response to

Browse pgsql-hackers by date

  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