Re: A qsort template - Mailing list pgsql-hackers

From Andres Freund
Subject Re: A qsort template
Date
Msg-id 20220403163256.ythjrgtwe2nbwajc@alap3.anarazel.de
Whole thread Raw
In response to Re: A qsort template  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: A qsort template
List pgsql-hackers
Hi,

On 2022-04-03 17:46:28 +1200, Thomas Munro wrote:
> On Sun, Apr 3, 2022 at 11:11 AM Andres Freund <andres@anarazel.de> wrote:
> > On 2022-04-03 09:45:13 +1200, Thomas Munro wrote:
> > > I think we just need to decide up front if we're in a situation that
> > > can't provide datum1/isnull1 (in this case because it's an expression
> > > index), and skip the optimised paths.  Here's an experimental patch...
> > > still looking into whether there are more cases like this...
> 
> I didn't find anything else.
> 
> Maybe it'd be better if we explicitly declared whether datum1 is used
> in each tuplesort mode's 'begin' function, right next to the code that
> installs the set of routines that are in control of that?  Trying that
> in this version.  Is it clearer what's going on like this?

Seems an improvement.


> > I'm a bit worried that none of the !ubsan tests failed on this...
> 
> In accordance with whoever-it-was-that-said-that's law about things
> that aren't tested, this are turned out to be broken already[1].

Yea :/.


Would be good to get this committed soon, so we can see further ubsan
violations introduced in the next few days (and so I can unblock my local dev
tests :P).

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fix overflow in DecodeInterval
Next
From: Andres Freund
Date:
Subject: Re: Enables to call Unregister*XactCallback() in Call*XactCallback()