Re: should check interrupts in BuildRelationExtStatistics ?
От | Tom Lane |
---|---|
Тема | Re: should check interrupts in BuildRelationExtStatistics ? |
Дата | |
Msg-id | 2031362.1657061281@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | should check interrupts in BuildRelationExtStatistics ? (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: should check interrupts in BuildRelationExtStatistics ?
|
Список | 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
В списке pgsql-hackers по дате отправления: