Or don't. You know that combination is tempting fate.
I love postgres. It's so great. The very best thing I can say about software is you have to tempt fate to get bitten by a bug.
don't do that if you value your uptime at all. Long-running transactions are the bane of any Postgres setup, no matter the XID overflow.
A few weeks ago, one slipped through my monitoring and a cache table we often sequence scan which normally had 10k rows in it had 28M dead rows that could never be removed due to that one transaction.
That sequence scan suddenly became a lot more expensive.
It depends on the write load, the read load, and the write patterns.
Think about it this way: for the duration of any transaction, Postgres is basically in append-only mode.
If you have cache tables that normally get rewritten entirely, no row will be deleted during the duration of any transaction in the whole cluster (so this even affects databases other than the one the transaction is connected to).
In our case, we run some heavy import jobs daily which causes transaction lifetimes in hours, depending on the job. This isn't an issue, or rather, it's an issue, you can throw hardware at in order to circumvent it.
The transaction I was referring to in my earlier comment had a lifetime in days and nearly brought down the whole system.