Re: should check interrupts in BuildRelationExtStatistics ?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Michael Paquier <michael@paquier.xyz>,
Robert Haas <robertmhaas@gmail.com>,
Tomas Vondra <tomas.vondra@enterprisedb.com>,
pgsql-hackers@postgresql.org
Date: 2022-07-05T23:37:03Z
Lists: pgsql-hackers
I wrote: >>> I modestly propose the attached. I'm not sure if it's >>> okay to back-patch this, because maybe someone out there >>> is relying on qsort() to be incapable of throwing an error I thought I'd better try to check that, and I soon found several places that *are* relying on qsort() to not be any smarter than the libc version. Notably, guc.c qsorts its persistent-state GUC array during add_guc_variable --- an interrupt there would leave the GUC data structure in an inconsistent state. There are lesser hazards, typically memory leaks, elsewhere. So I fear this can't fly as-is. 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. regards, tom lane
Commits
-
Invent qsort_interruptible().
- e64cdab00302 16.0 landed
- af72b0889441 14.5 landed
- 12c99c88442d 15.0 landed