On Tue, Jun 7, 2016 at 3:24 PM, Alexandre Garcia <alexandre@xxxxxxxxxxx> wrote: > No old transactions are sitting in pg_stat_activity nor pg_prepared_xacts. > But since it was few weeks ago, it might have been the case before. > But that doesn't explain why that directory is still so big. When the SERIALIZABLE transaction isolation level was upgraded to truly serializable behavior in release 9.1, the committer at the time insisted on leaving the files in the pg_serial directory on shutdown and startup in case anyone wanted to dig through them for debugging purposes -- they have no operational value across restarts. If you reached wraparound because of a very old transaction, the directory should slowly shrink again as transaction IDs advance, and the safe thing to do (after confirming this behavior) would be to just let that happen. Theoretically, deleting the files in that directory WHILE THE DATABASE SERVICE IS STOPPED should be safe, but I have never done that, and would not recommend it unless the disk space issue is critical because of it and you make a backup of the directory first. Direct modification of any internal files like that should always be considered high risk, and that risk carefully balanced against the expected benefit. Hopefully you can see a gap in the file numbers, and see that it is expanding over time, and can just let the problem sort itself out. You may want to add some sort of monitoring for old prepared transactions and idle transactions to prevent a recurrence. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
