| 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: | Whole Thread | Raw Message | 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 |