| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: GIN pending clean up is not interruptable |
| Date: | 2015-08-11 22:27:15 |
| Message-ID: | 20150811222715.GA8470@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2015-08-11 15:07:15 -0700, Jeff Janes wrote:
> When a user backend (as opposed to vacuum or autoanalyze) gets burdened
> with cleaning up the GIN pending list, it does not
> call CHECK_FOR_INTERRUPTS().
>
> Since cleaning does a lot of random IO, it can take a long time and it is
> not nice to be uninterruptable.
Agreed.
> The attached patch adds an else branch to call CHECK_FOR_INTERRUPTS().
>
> But I think we could instead just call vacuum_delay_point unconditionally.
> It calls CHECK_FOR_INTERRUPTS(), and if not in a throttled vacuum it does
> nothing else. (That is how ANALYZE handles it.)
Hm, I find that not exactly pretty. I'd rather just add an unconditional
CHECK_FOR_INTERRUPTS to the function.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gurjeet Singh | 2015-08-11 22:59:59 | Re: replication slot restart_lsn initialization |
| Previous Message | Robert Haas | 2015-08-11 22:21:14 | Re: Foreign join pushdown vs EvalPlanQual |