| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | Creston Jamison <creston(dot)jamison(at)rubytreesoftware(dot)com> |
| Cc: | Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Autovacuum Truncation Phase Loop? |
| Date: | 2020-12-12 17:08:35 |
| Message-ID: | CAMkU=1wn53MQzE1D0ePeLXtYrs65U80TsbCLxHc4cH_n1T0e=A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On Mon, Nov 9, 2020 at 11:43 AM Creston Jamison <
creston(dot)jamison(at)rubytreesoftware(dot)com> wrote:
>
> 2020-11-04 16:34:47.635 UTC [894681-1] ERROR: canceling autovacuum task
> 2020-11-04 16:34:47.635 UTC [894681-2] CONTEXT: automatic vacuum of table
> "x.pg_toast.pg_toast_981540"
>
> Based upon Googling, we suspect it is the truncation step of autovacuum
> and its ACCESS EXCLUSIVE lock attempt(s).
>
No, I think that would lead to different messages explicitly mentioning
truncation. (or no messages in most cases, as I think those messages only
get logged either for 'vacuum verbose' or when log_min_messages = debug2 or
higher). So something else is going on.
Are these vacuums happening for wrap around? I don't know why else they
would restart so aggressively. On the other hand if they were for wrap
around, they shouldn't be allowing themselves to get canceled so easily in
the first place.
You mention a manual vacuum resolves the issue. For how long does it stay
resolved?
Cheers,
Jeff
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tim Cross | 2020-12-12 22:48:11 | Re: How to turnoff autovacuum |
| Previous Message | Oleksandr Mazyar | 2020-12-12 17:07:45 | Re: How to turnoff autovacuum |