From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: should check interrupts in BuildRelationExtStatistics ? |
Date: | 2022-05-09 03:31:16 |
Message-ID: | YniLBN/x8N97ZDzf@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-05-09 03:36:33 | Re: should check interrupts in BuildRelationExtStatistics ? |
Previous Message | Michael Paquier | 2022-05-09 03:18:39 | Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set |