| From: | Michael Lewis <mlewis(at)entrata(dot)com> |
|---|---|
| To: | Jim Hurne <jhurne(at)us(dot)ibm(dot)com> |
| Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: autovacuum failing on pg_largeobject and disk usage of the pg_largeobject growing unchecked |
| Date: | 2020-06-23 20:44:51 |
| Message-ID: | CAHOFxGoOaVk6KPQgrijZAfrbAdkwW3jQZTjb=swOXU4dk8MidQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Tue, Jun 23, 2020 at 2:34 PM Jim Hurne <jhurne(at)us(dot)ibm(dot)com> wrote:
> Sure! Below are more of the details from the same set of logs. Looking at
> them myself, I see that there is always some percentage of tuples that are
> dead but are not yet removable. And that number increases on every vacuum,
> which might explain in part why autovacuum elapsed times keep increasing.
>
> What causes a dead tuple to be unremovable?
>
Here are a couple good write ups.
https://www.cybertec-postgresql.com/en/reasons-why-vacuum-wont-remove-dead-rows/
https://www.2ndquadrant.com/en/blog/when-autovacuum-does-not-vacuum/
Long running transactions are the common one that I see. You might be
dealing with replication slots or prepared transactions. Basically, if some
process might see that "old truth", then it can't be vacuumed away yet.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Lewis | 2020-06-23 20:51:58 | Re: Persistent Connections |
| Previous Message | Jim Hurne | 2020-06-23 20:34:03 | RE: autovacuum failing on pg_largeobject and disk usage of the pg_largeobject growing unchecked |