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

From Michael Paquier
Subject Re: should check interrupts in BuildRelationExtStatistics ?
Date
Msg-id YniLBN/x8N97ZDzf@paquier.xyz
Whole thread Raw
In response to should check interrupts in BuildRelationExtStatistics ?  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
On Sun, May 08, 2022 at 07:01:08PM -0500, Justin Pryzby wrote:
> Restarting a large instance took twice as long as I expected due to not
> checking interrupts in (at least) statext_ndistinct_build.  Long enough that I
> attached (and was able to attach) a debugger to verify, which I think is too
> long.  I think it could cause issues for an high-availability cluster or other
> script if it takes too long to shut down.

Hmm.  That's annoying.

> The tables being auto-analyzed have 9 exteneded stats objects, each with stats
> target=10.  7 of those are (ndistinct) stats on 4 simple columns plus 1
> expression (5 total).  And the other 2 stats objects are expressional stats
> (necessarily on a single expression).

How long can the backend remain unresponsive?  I don't think that
anybody would object to the addition of some CHECK_FOR_INTERRUPTS() in
areas where it would be efficient to make the shutdown quicker, but
we need to think carefully about the places where we'd want to add
these.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
Next
From: Tom Lane
Date:
Subject: Re: should check interrupts in BuildRelationExtStatistics ?