| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: should check interrupts in BuildRelationExtStatistics ? |
| Date: | 2022-07-05 23:49:46 |
| Message-ID: | YsTOGq30GhkWPCT+@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jul 05, 2022 at 07:37:03PM -0400, Tom Lane wrote:
> Nonetheless, it'd be a good idea to use an interruptible sort in
> as many places as we can. If we don't mind YA copy of the qsort
> code, I'd be inclined to propose inventing qsort_interruptible
> which is like qsort_arg but also does CHECK_FOR_INTERRUPTS.
> (There seems no reason to support a non-arg version, since you
> can just pass NULL.) Or we could redefine qsort_arg as allowing
> interrupts, but that might still carry some surprises for existing
> code.
Agreed to use a new and different API for this purpose. It seems like
a tool where one could write some new code and use an interruptible
qsort() thinking that it is fine, still a preperly-documented API has
clear benefits.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2022-07-05 23:57:24 | Re: avoid multiple hard links to same WAL file after a crash |
| Previous Message | Bruce Momjian | 2022-07-05 23:47:52 | Re: First draft of the PG 15 release notes |