Re: Logical decoding on standby
От | Craig Ringer |
---|---|
Тема | Re: Logical decoding on standby |
Дата | |
Msg-id | CAMsr+YGZZeHNMB6oSN6hpNvk-_j+1rsVaGT-ramiukPhsFaa0w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Logical decoding on standby (Craig Ringer <craig@2ndquadrant.com>) |
Список | pgsql-hackers |
On 29 March 2017 at 16:44, Craig Ringer <craig@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
В списке pgsql-hackers по дате отправления: