Investigate tuple freezing and wrapping of transaction IDs

• http://www.databasesoup.com/2012/09/freezing-your-tuples-off-part-1.html
• http://www.databasesoup.com/2012/10/freezing-your-tuples-off-part-2.html

Output from the primary GitLab.com database:

gitlabhq_production=# SELECT relname, age(relfrozenxid) as xid_age,
gitlabhq_production-#     pg_size_pretty(pg_table_size(oid)) as table_size
gitlabhq_production-# FROM pg_class
gitlabhq_production-# WHERE relkind = 'r' and pg_table_size(oid) > 1073741824
gitlabhq_production-# ORDER BY age(relfrozenxid) DESC LIMIT 20;
          relname           |  xid_age  | table_size
----------------------------+-----------+------------
 events                     | 159771925 | 111 GB
 services                   | 159702567 | 5837 MB
 merge_requests             | 143889762 | 1402 MB
 merge_request_diffs        | 138813134 | 130 GB
 snippets                   | 138662865 | 4285 MB
 ci_commits                 | 136168324 | 1241 MB
 issues                     | 114392752 | 6944 MB
 pg_stat_statements_history | 107571522 | 7500 MB
 audit_events               | 107515808 | 1798 MB
 sent_notifications         | 107477250 | 1635 MB
 notes                      |  58563803 | 8232 MB
 ci_builds                  |  54297799 | 9815 MB
(12 rows)

Here we have a bunch of tables coming close to the 200 million limit. All of these are large enough that getting hit by a vacuum freeze will be anything but pleasant.