On 29 March 2017 at 16:44, Craig Ringer <cr...@2ndquadrant.com> wrote:
> * Split oldestCatalogXmin tracking into separate patch Regarding this, Simon raised concerns about xlog volume here. It's pretty negligible. We only write a new record when a vacuum runs after catalog_xmin advances on the slot with the currently-lowest catalog_xmin (or, if vacuum doesn't run reasonably soon, when the bgworker next looks). So at worst on a fairly slow moving system or one with a super high vacuum rate we'll write one per commit. But in most cases we'll write a lot fewer than that. When running t/006_logical_decoding.pl for example: $ ../../../src/bin/pg_waldump/pg_waldump tmp_check/data_master_daPa/pgdata/pg_wal/000000010000000000000001 | grep CATALOG rmgr: Transaction len (rec/tot): 4/ 30, tx: 0, lsn: 0/01648D50, prev 0/01648D18, desc: CATALOG_XMIN catalog_xmin 555 rmgr: Transaction len (rec/tot): 4/ 30, tx: 0, lsn: 0/0164C840, prev 0/0164C378, desc: CATALOG_XMIN catalog_xmin 0 pg_waldump: FATAL: error in WAL record at 0/16BBF10: invalid record length at 0/16BBF88: wanted 24, got 0 and of course, none at all unless you use logical decoding. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
