On Tue, May 17, 2016 at 10:40 AM Alvaro Herrera
wrote:
> In 9.4, not really. In 9.5 there's a function mxid_age() that gives you
> the age of a multixact, so you'd grab the oldest from
> pg_database.datminmxid and compute the age of that one. Going from the
> oldest
Steve Kehlet wrote:
> On Mon, May 16, 2016 at 6:18 PM Alvaro Herrera
> wrote:
>
> > Not really. Your best bet is to reduce the
> > autovacuum_multixact_freeze_min_age limit, so that vacuums are able to
> > get rid of multixacts sooner (and/or reduce
> >
On Mon, May 16, 2016 at 6:18 PM Alvaro Herrera
wrote:
> Not really. Your best bet is to reduce the
> autovacuum_multixact_freeze_min_age limit, so that vacuums are able to
> get rid of multixacts sooner (and/or reduce
> autovacuum_multixact_freeze_table_age, so that
Steve Kehlet wrote:
> Now it's just about preventing this. Our best guess at this point is the
> autovacuums aren't working fast enough. Sure enough this instance has our
> old values for:
> autovacuum_vacuum_cost_delay: 20ms
> autovacuum_vacuum_cost_limit: 200
>
> We've since started using:
>
This is Postgres 9.4.4. Custom settings are [in this gist](
https://gist.github.com/skehlet/47c7f92daa0bd3d1a3aee2bb001da140).
This is a new one for me, one of our bigger (~2.2TB) databases started
having the following error:
> Caused by: org.postgresql.util.PSQLException: ERROR: multixact