Re: Multixact members limit exceeded

From: Andres Freund <andres(at)anarazel(dot)de>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Peter Hunčár <hunci(at)hunci(dot)sk>, pgsql-general(at)postgresql(dot)org
Subject: Re: Multixact members limit exceeded
Date: 2017-08-09 20:39:49
Message-ID: 20170809203949.drttkvpcibpgrsgn@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi,

On 2017-08-09 16:30:03 -0400, Alvaro Herrera wrote:

> > One particular table before vacuum full:
> >
> > relname | relminmxid | table_size
> > ------------------------------+------------+------------
> > delayed_jobs | 1554151198 | 21 GB
> >
> > And after vacuum full:
> >
> > relname | relminmxid | table_size
> > --------------+------------+------------
> > delayed_jobs | 1554155465 | 6899 MB
> >
> > Shouldn't be the relminmxid changed after vacuum full, or am I not
> > understanding something?

FWIW, VACUUM FULL isn't a good tool to use here. It's commonly way more
expensive than a normal vacuum (it rewrites the entire table, and
rebuilds indexes).

> But it did change ... the problem is that it didn't change enough (only
> 4000 multixacts). Maybe your multixact freeze min age is too high?
> Getting rid of 15 GB of bloat is a good side effect, though, I'm sure.

I wonder if there's longrunning transactions preventing cleanup. I
suggest checking pg_stat_activity, pg_prepared_xacts,
pg_replication_slot for older stuff.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message marcelo 2017-08-09 20:49:30 ErrorCode=-2147467259 storing a .net string
Previous Message Alvaro Herrera 2017-08-09 20:30:03 Re: Multixact members limit exceeded