Re: [GENERAL] Multixact members limit exceeded - Mailing list pgsql-general

From Andres Freund
Subject Re: [GENERAL] Multixact members limit exceeded
Date
Msg-id 20170809203949.drttkvpcibpgrsgn@alap3.anarazel.de
Whole thread Raw
In response to Re: [GENERAL] Multixact members limit exceeded  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: [GENERAL] Multixact members limit exceeded  (Peter Hunčár <hunci@hunci.sk>)
List 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


pgsql-general by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [GENERAL] Multixact members limit exceeded
Next
From: marcelo
Date:
Subject: [GENERAL] ErrorCode=-2147467259 storing a .net string