Hi all, I have a few questions related to recovering from a near-miss with transactionid wraparound. I'm currently running a vacuum freeze in single user mode on our largest database (about 36 TB). It's been running for about 10 days (since the database shut itself down to avoid xid wraparound). One cpu has been basically running at 100% the whole time (except during short periods of write activity when it drops briefly to around 30%). Any idea how to guess how long this might take? Is there anything I can adjust to speed the vacuum freeze up? It seems to be CPU limited--can anyone tell me what it would be doing that is so CPU intensive? Runs postgres 9.1.9 on FreeBSD 9.1 with ZFS, database was built --with-segsize=10, storage is a pool of 20 2-disk mirrors Maintenance_work_mem is set to 10GB; there is about 48 GB of memory in the machine. The size of our database may be unusual for postgres, but honestly, it has performed quite well for us over the years. Our trouble comes when every once in a while we get a perfect storm that causes the autovacuum to fall behind. We are generally very careful to try to keep this from happening, since all it takes is one query at the wrong time to take a large database offline for days (or weeks). This is definitely our biggest cause of postgres outages, taking one of our databases offline about once a year, it seems. With the speed postgres is capable of, and the ever-falling prices of storage making larger, faster databases possible, has the possibility of changing the transaction id to a 64-bit (or even 128-bit!) value been considered? Thanks! Natalie -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
