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-05T22:48:01Z
Lists: pgsql-hackers
Justin Pryzby <pryzby@telsasoft.com> writes: > On Fri, Jul 01, 2022 at 07:19:11PM -0400, Tom Lane wrote: >> That, um, piqued my interest. After a bit of digging, >> 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 >> --- but it'd solve the problem at hand and a bunch of other >> issues of the same ilk. > Confirmed this fixes the 3 types of extended stats, at least for the example > cases I made. > If it's okay to backpatch, v14 seems adequate since the problem is more > prominent with expressional statistics (I'm sure that's why I hit it) ... > otherwise v15 would do. After thinking for awhile, my inclination is to apply my patch in HEAD and yours in v15/v14. We have a year to find out if there's any problem with the more invasive check if we do it in HEAD; but there's a lot less margin for error in v14, and not that much in v15 either. regards, tom lane
Commits
-
Invent qsort_interruptible().
- e64cdab00302 16.0 landed
- af72b0889441 14.5 landed
- 12c99c88442d 15.0 landed