| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | MichaelDBA <MichaelDBA(at)sqlexec(dot)com> |
| Cc: | Mike Schanne <mschanne(at)kns(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: autovacuum locking question |
| Date: | 2019-12-07 00:59:00 |
| Message-ID: | CAMkU=1xxTrCBUUXM2KtJPa0sk4ZgZUsxHo52SdqVXR-=VU2Dtw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Fri, Dec 6, 2019 at 12:50 PM MichaelDBA <MichaelDBA(at)sqlexec(dot)com> wrote:
> And Just to reiterate my own understanding of this...
>
> autovacuum priority is less than a user-initiated request, so issuing a
> manual vacuum (user-initiated request) will not result in being cancelled.
>
Somethings happen in some situations and not in others. I don't know that
it is useful to categorize them into a monotonic priority scale.
Autovacs "to prevent wraparound" don't get cancelled the way ordinary
autovacs do, but they still use autovac IO throttling settings, not the
unthrottled (by default settings) manual vacuum settings, which can be a
major problem sometimes.
Note that no kind of vacuum should normally get cancelled using the
signalling mechanism during truncation phase, that seems to be due to some
rather extreme situation with IO congestion.
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ondrej Ivanič | 2019-12-07 01:23:15 | Re: How to run in parallel in Postgres |
| Previous Message | Justin Pryzby | 2019-12-06 23:28:49 | Re: unexpected result for wastedbytes query after vacuum full |