Tiffany Thang <tiffanyth...@gmail.com> writes:
> Our pg_multixact/members directory has been growing to more than 18GB over
> the last couple of months. According to the documentation, the files in
> there are used to support row locking by multiple transactions and when all
> tables in all databases are eventually scanned by VACUUM, the older
> multixacts are removed. In our case, the files are not removed.
Hmm. What does pg_controldata tell you about NextMultiXactId,
NextMultiOffset, oldestMultiXid, oldestMulti's DB?
Are pg_clog/ or pg_subtrans/ or pg_multixact/offsets/ getting large?
Is there anything at all in pg_twophase/? Is this system a replication
master, and if so are any of its slaves lagging behind?
> Any
> suggestions what I should do to purge the files automatically? Can old
> files since the last reboot be manually removed?
I wouldn't do that. Much safer to figure out what's blocking automatic
cleanup so you can fix the root cause.
regards, tom lane
