Re: autovacuum failing on pg_largeobject and disk usage of thepg_largeobject growing unchecked - Mailing list pgsql-general

From Michael Lewis
Subject Re: autovacuum failing on pg_largeobject and disk usage of thepg_largeobject growing unchecked
Date
Msg-id CAHOFxGrvmJR+vHpZm3omkVpfLr+c8vrCq+qJArFKSzArFD_MAw@mail.gmail.com
Whole thread Raw
In response to autovacuum failing on pg_largeobject and disk usage of the pg_largeobjectgrowing unchecked  ("Jim Hurne" <jhurne@us.ibm.com>)
Responses RE: autovacuum failing on pg_largeobject and disk usage of thepg_largeobject growing unchecked  ("Jim Hurne" <jhurne@us.ibm.com>)
List pgsql-general
On Tue, Jun 16, 2020 at 10:01 AM Jim Hurne <jhurne@us.ibm.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.

pgsql-general by date:

Previous
From: Aleš Zelený
Date:
Subject: Re: Logical replication - ERROR: could not send data to WAL stream:cannot allocate memory for input buffer
Next
From: "Jim Hurne"
Date:
Subject: RE: autovacuum failing on pg_largeobject and disk usage of thepg_largeobject growing unchecked