Tiffany Thang <tiffanythang@xxxxxxxxx> 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
