Re: glibc qsort() vulnerability - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: glibc qsort() vulnerability
Date
Msg-id 20240207222124.GA382832@nathanxps13
Whole thread Raw
In response to Re: glibc qsort() vulnerability  (Andres Freund <andres@anarazel.de>)
Responses Re: glibc qsort() vulnerability
List pgsql-hackers
On Wed, Feb 07, 2024 at 01:48:57PM -0800, Andres Freund wrote:
> Now, in most cases this won't matter, the sorting isn't performance
> critical. But I don't think it's a good idea to standardize on a generally
> slower pattern.
> 
> Not that that's a good test, but I did quickly benchmark [1] this with
> intarray. There's about a 10% difference in performance between using the
> existing compASC() and one using
>     return (int64) *(const int32 *) a - (int64) *(const int32 *) b;
> 
> 
> Perhaps we could have a central helper for this somewhere?

Maybe said helper could use __builtin_sub_overflow() and fall back to the
slow "if" version only if absolutely necessary.  The assembly for that
looks encouraging, but I still need to actually test it...

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: James Coleman
Date:
Subject: Re: Question about behavior of deletes with REPLICA IDENTITY NOTHING
Next
From: Peter Smith
Date:
Subject: Re: Question about behavior of deletes with REPLICA IDENTITY NOTHING