We are running Postgresql 9.3.8. We had something fairly surprising happen
here the other day: we started reaching the vacuum limit, with our logs
filling up with “WARNING: database "mydb" must be vacuumed within
177009986 transactions” messages, hundreds of them per second, and we came
dangerously close to experiencing a DB shutdown. *However*, there were only
three things running that were writing to the database - a db-wide VACUUM
that we manually started, a per-table autovacuum that postgres itself
started, and a "write 1 row every 1-minute" cron job into a separate table
that we use to track replication delay.

Whenever we killed the autovacuum process, the very fast incrementation of
the transaction IDs would stop. Then, a few minutes later, PG would restart
the autovacuum process, and then very soon after that, the transaction IDs
would start incrementing again very quickly.

Modifying postgresql.conf to turn off autovacuums didn't prevent
auto-vacuuming from restarting, in-line with documentation that says that
autovacuums will start whenever postgres is in danger of running out of
transaction IDs.

We ended up writing a script that would check the running processes and
continuously kill autovacuums as they started. We were able to get the
manual vacuum to finish without running out of transaction IDs and without
experiencing a shut-down, but the entire experience was slightly concerning.

Did we hit upon a known edge case where two vacuum processes running in
parallel would increment transaction IDs very quickly?