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

From Nathan Bossart
Subject Re: glibc qsort() vulnerability
Date
Msg-id 20240209163245.GB663211@nathanxps13
Whole thread Raw
In response to Re: glibc qsort() vulnerability  ("Andrey M. Borodin" <x4mmm@yandex-team.ru>)
Responses Re: glibc qsort() vulnerability
List pgsql-hackers
On Fri, Feb 09, 2024 at 01:19:49PM +0500, Andrey M. Borodin wrote:
> If we care about branch prediction in comparison function, maybe we could
> produce sorting that inlines comparator, thus eliminating function call
> to comparator? We convert comparison logic to int, to extract comparison
> back then.
> 
> I bet “call" is more expensive than “if".

It might make sense to have a couple of built-in qsort implementations for
pointers to integers, pointers to unsigned integers, etc.  However, a lot
of current use-cases require inspecting specific fields of structs, so
(assuming I understand your proposal correctly), we'd end up with many
qsort implementations.  If that can be made simple and elegant and
demonstrates substantial improvements, then it might be worth considering,
but I'm somewhat skeptical that the current uses are performance-sensitive
enough to be worth the effort.

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: glibc qsort() vulnerability
Next
From: Nathan Bossart
Date:
Subject: Re: [PATCH] allow pg_current_logfile() execution under pg_monitor role