Re: [HACKERS] putting CHECK_FOR_INTERRUPTS in - Mailing list pgsql-patches

From Tom Lane
Subject Re: [HACKERS] putting CHECK_FOR_INTERRUPTS in
Date
Msg-id 20568.1154214313@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] putting CHECK_FOR_INTERRUPTS in  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [HACKERS] putting CHECK_FOR_INTERRUPTS in  (Bruce Momjian <bruce@momjian.us>)
List pgsql-patches
Bruce Momjian <bruce@momjian.us> writes:
> Are we done with the sort interrupt issue mentioned in the subject line,
> and the issue outlined below?

I'm inclined not to apply the proposed patch (adding
CHECK_FOR_INTERRUPTS) because of the risk of memory leakage inside
qsort.  OTOH you could argue that there's an unfixable risk of memory
leakage there anyway, because it's always possible that the invoked
datatype comparison routine exits with elog(ERROR) for some reason,
or even contains a CHECK_FOR_INTERRUPTS call itself.  Comments?

As for the question of whether we should try to detoast sort keys before
sorting, I'd suggest adding that to TODO.  Investigating whether this
would be a good idea will take more time than we have for 8.2, so it's
gonna have to wait for a future cycle.

            regards, tom lane

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] pg_regress breaks on msys
Next
From: Greg Sabino Mullane
Date:
Subject: New variable server_version_num