> Few weeks ago our customer experienced some spikes on his Postgres 9.4.5 > database. We've been alerted of a significant disk usage increase and > pg_serial seemed to be the culprit. > > We noticed a lot of those errors in the logs > > " could not truncate directory "pg_serial": apparent wraparound " > > No more errors now but the pg_serial is still 8G big and doesn't seem to > decrease. > The only thing I could find related to this was an old bug from 2011 which > might be fixed now. > > We wonder what is responsible for cleaning up the old transactions in > pg_serial and how it could dysfunction in this case.
Could you check your logs to see whether you got a warning like this?:
memory for serializable conflict tracking is nearly exhausted
With a hint like this?:
There might be an idle transaction or a forgotten prepared transaction causing this.
Please check pg_stat_activity and pg_prepared_xacts for very old transactions. You should not see the errors you are reporting nor the warning I mentioned unless a serializable transaction remains active long enough for about 1 billion transaction IDs to be consumed.
Hm. WARNING is probably not the right level for that, since that might not show in the log. It should probably be changed to LOG. Even better, now that filenames can go past 4 hex digits, we should eliminate the 1 billion limit for this.
