Re: should check interrupts in BuildRelationExtStatistics ? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: should check interrupts in BuildRelationExtStatistics ?
Date
Msg-id 2031362.1657061281@sss.pgh.pa.us
Whole thread Raw
In response to should check interrupts in BuildRelationExtStatistics ?  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: should check interrupts in BuildRelationExtStatistics ?
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_checkpointer is not a verb or verb phrase
Next
From: Andres Freund
Date:
Subject: Re: should check interrupts in BuildRelationExtStatistics ?