From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Rodrigo Barboza <rodrigombufrj(at)gmail(dot)com> |
Cc: | pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: auto vaccum is dying |
Date: | 2014-10-02 15:34:35 |
Message-ID: | CAMkU=1x2dtFxMECp8jBhcGEekK+aGHSfOaOBtkcV3d4M378T7g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wed, Oct 1, 2014 at 9:43 PM, Rodrigo Barboza <rodrigombufrj(at)gmail(dot)com>
wrote:
> Hello, I have a table that receives lots of updates and inserts.
> Auto vaccum is always being cancelled on that table.
>
Do you have a scheduled task that clusters or reindexes the table?
Newer versions of PostgreSQL will log the conflicting statement that caused
the vacuum to cancel.
> One day the database went on standby and I had to act manually to recover.
>
I'm not sure what that means. Do you mean it stopped accepting commands to
prevent "wrap around" data loss? Once autovacuum starts running on a table
in "prevent wrap around", then it no longer voluntarily yields to other
processes trying to take a conflicting lock.
>
> What should I do to avoid auto vaccum cancel?
>
If you have scheduled jobs that do something on the table that requires a
lock which conflicts with autovac, then you might want to include a manual
VACUUM in that job.
Also, what full version are you running?
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2014-10-02 19:56:27 | Re: Yet another abort-early plan disaster on 9.3 |
Previous Message | Ryan Johnson | 2014-10-02 13:59:00 | Re: Yet another abort-early plan disaster on 9.3 |