Horton

Re: scalability bottlenecks with (many) partitions (and more)

Tomas Vondra <tomas@vondra.me>

View thread
From: Tomas Vondra <tomas@vondra.me>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jakub Wartak <jakub.wartak@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Andres Freund <andres@anarazel.de>
Date: 2024-09-22T22:50:41Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Make FP_LOCK_SLOTS_PER_BACKEND look like a function

  2. Fix asserts in fast-path locking code

  3. Increase the number of fast-path lock slots

On 9/22/24 17:45, Tom Lane wrote:
> Tomas Vondra <tomas@vondra.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