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 ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_checkpointer is not a verb or verb phrase
Следующее
От: Andres Freund
Дата:
Сообщение: Re: should check interrupts in BuildRelationExtStatistics ?