| From: | Don Seiler <don(at)seiler(dot)us> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Postgres General <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: template0 needing vacuum freeze? |
| Date: | 2020-05-16 17:51:53 |
| Message-ID: | CAHJZqBB=u7YGqsQUVEy0NNsujfuq3VntGnD4efpP6F4GWhsaHQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Sat, May 16, 2020 at 12:44 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> So it's unsurprising that the freeze age increases until autovacuum
> decides to do something about it. I'm suspicious that your alert settings
are too aggressive and are notifying you before autovacuum kicks in.
> You should *not* have had to do anything manual about this, unless you
> have frobbed your autovac settings to the point of brokenness.
>
Shouldn't autovacuum have kicked in when the age of a table reaches 200M
(our autovacuum_freeze_max_age is left at that default)? I see other tables
in our app DB triggering the autovacuum "to prevent wrap-around" when they
reach 200M. That's what had me concerned to see template0 with an age over
1B and no autovacuum even trying to clean up for it.
Don.
--
Don Seiler
www.seiler.us
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Łukasz Dąbek | 2020-05-16 17:56:20 | Using b-tree index for >= condition when joining |
| Previous Message | Tom Lane | 2020-05-16 17:44:34 | Re: template0 needing vacuum freeze? |