From: | Tomas Vondra <tomas(at)vondra(dot)me> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: scalability bottlenecks with (many) partitions (and more) |
Date: | 2024-09-22 22:50:41 |
Message-ID: | 5a5be673-4102-4c52-b504-1b205d5b7f83@vondra.me |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 9/22/24 17:45, Tom Lane wrote:
> Tomas Vondra <tomas(at)vondra(dot)me> writes:
>> I've finally pushed this, after many rounds of careful testing to ensure
>> no regressions, and polishing.
>
> Coverity is not terribly happy with this. "Assert(fpPtr = fpEndPtr);"
> is very clearly not doing what you presumably intended. The others
> look like overaggressive assertion checking. If you don't want those
> macros to assume that the argument is unsigned, you could force the
> issue, say with
>
> #define FAST_PATH_GROUP(index) \
> - (AssertMacro(((index) >= 0) && ((index) < FP_LOCK_SLOTS_PER_BACKEND)), \
> + (AssertMacro((uint32) (index) < FP_LOCK_SLOTS_PER_BACKEND), \
> ((index) / FP_LOCK_SLOTS_PER_GROUP))
>
Ah, you're right. I'll fix those asserts tomorrow.
The first is clearly wrong, of course.
For the (x >= 0) asserts, doing it this way relies on negative values
wrapping to large positive ones, correct? AFAIK it's guaranteed to be a
very large value, so it can't accidentally be less than the slot count.
regards
--
Tomas Vondra
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-09-22 23:06:46 | Re: scalability bottlenecks with (many) partitions (and more) |
Previous Message | David Rowley | 2024-09-22 22:44:58 | Re: [PATCH] Re: Proposal to Enable/Disable Index using ALTER INDEX |