I recently got few DBs to maintain. I just come up about this "Preventing Transaction ID Wraparound Failures". I checked my DBs and got the numbers: enter image description here

I did vacuumdb -a -v on this DB, and then got the numbers: enter image description here

In my opinion it is not good enough? Should I worry?

If I understand correctly by PostgreSQL manual, should I use vacuum freeze to reset counters to zero? I know that this db steadly will grow, usualy on inserts, not so for deletes/updates.

Thank you.

  • What version of PostgreSQL are you using? More recent versions have better tools available to manage wraparound.
    – dwhitemv
    Oct 21, 2021 at 14:34
  • I'm using psql (9.3.20)
    – Gumuliokas
    Oct 22, 2021 at 4:23

2 Answers 2


The failure limit is 2,000,000,000, which is ten times more than the autovacuum_freeze_max_age cutoff of 200,000,000. So there is nothing to worry about there, you are very far from failure and it will automatically kick in in plenty of time.

But once an anti-wraparound vacuum does kick in, it might cause inconvenience due to the table lock. So you might want to do freezing (like with -F flag to vacuumdb) at a time of your choosing to preempt it from happening automatically at some time out of your control.


No, VACUUM will not freeze all rows, so it won't set datfrozenxid to the current transaction ID.

  • VACUUM won't freeze any row that is less than vacuum_freeze_min_age transactions old (default 50 million).

    Rows that have remain unmodified for a while have good odds of staying around, so it is worth freezing them. New rows will often get deleted or updated soon, in which case freezing them (which causes a write!) would be a loss.

  • VACUUM will skip all blocks that are “all-visible”, so rows on those pages won't be frozen.

  • VACUUM will skip pages that it cannot get a lock on because they are pinned.

The second and third point don't apply to an anti-wraparound (“aggressive”) autovacuum run; such a process really wants to visit all pages that are not “all-frozen”.

Everything is fine with your database. It is good for performance if rows don't get frozen too early.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.