From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_multixact not getting truncated |
Date: | 2014-11-04 01:06:57 |
Message-ID: | 20141104010657.GX1791@alvin.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus wrote:
> Hackers,
>
> I'm looking at a couple of high-transaction-rate and high-FK-conflict
> rate servers where pg_multixact has grown to be more than 1GB in size.
> One such server doesn't appear to be having any notable issues with
> vacuuming, and the oldest mxid on the system is about 47m old. VACUUM
> FREEZEing the oldest databases did not cause the pg_multixact dir to get
> smaller --- it may have even caused it to get larger.
>
> Why would pg_multixact not be truncating? Does it never truncate files
> with aborted multixacts in them? Might we have another multixact bug?
Have a look at the MultiXactId values in pg_controldata, datminmxid in
pg_database, and relminmxid in pg_class. They should advance as you
VACUUM FREEZE. If it's stuck at 1, you might be in pg_upgrade trouble
if you used 9.3.4 or earlier to upgrade.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-11-04 01:10:05 | Re: Pipelining executions to postgresql server |
Previous Message | Alvaro Herrera | 2014-11-04 00:59:23 | Re: BRIN indexes - TRAP: BadArgument |