| From: | Michael Lewis <mlewis(at)entrata(dot)com> |
|---|---|
| To: | Jim Hurne <jhurne(at)us(dot)ibm(dot)com> |
| Cc: | 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-16 17:05:35 |
| Message-ID: | CAHOFxGrvmJR+vHpZm3omkVpfLr+c8vrCq+qJArFKSzArFD_MAw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Tue, Jun 16, 2020 at 10:01 AM Jim Hurne <jhurne(at)us(dot)ibm(dot)com> wrote:
> Other than the increasing elapsed times for the autovacuum, we don't see
> any other indication in the logs of a problem (no error messages, etc).
>
> We're currently using PostgreSQL version 10.10. Our service is JVM-based
> and we're using the PostgreSQL JDBC driver version 42.2.5.
>
> Have we stumbled upon a potential bug here, or do we need to tweak some
> autovacuum settings? What should we look at next or what should we try
> next to further troubleshoot this?
>
What are your current autovacuum settings? Do you have long
running transactions with any frequency? Decreasing
autovacuum_vacuum_cost_delay to 1 or 2ms may be prudent (default changes
from 20ms down to 2ms with PG 12). Is this a destructive queue of sorts
with no rows permanently stored? If so, I would expect that a daily
scheduled vacuum analyze may be the best course of action.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Hurne | 2020-06-16 19:45:07 | RE: autovacuum failing on pg_largeobject and disk usage of the pg_largeobject growing unchecked |
| Previous Message | Aleš Zelený | 2020-06-16 16:29:55 | Re: Logical replication - ERROR: could not send data to WAL stream: cannot allocate memory for input buffer |