Re: Autovacuum Truncation Phase Loop? - Mailing list pgsql-admin

From Jeff Janes
Subject Re: Autovacuum Truncation Phase Loop?
Date
Msg-id CAMkU=1wn53MQzE1D0ePeLXtYrs65U80TsbCLxHc4cH_n1T0e=A@mail.gmail.com
Whole thread Raw
In response to Autovacuum Truncation Phase Loop?  (Creston Jamison <creston.jamison@rubytreesoftware.com>)
Responses Re: Autovacuum Truncation Phase Loop?  (Laurenz Albe <laurenz.albe@cybertec.at>)
List pgsql-admin
On Mon, Nov 9, 2020 at 11:43 AM Creston Jamison <creston.jamison@rubytreesoftware.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

pgsql-admin by date:

Previous
From: Oleksandr Mazyar
Date:
Subject: Re: How to turnoff autovacuum
Next
From: Tim Cross
Date:
Subject: Re: How to turnoff autovacuum