Re: Logical decoding fast-forward and slot advance
От | Simon Riggs |
---|---|
Тема | Re: Logical decoding fast-forward and slot advance |
Дата | |
Msg-id | CANP8+jKfPG_6PO=BAVS-1DJhWnitjCBT_VjwpqxhLY_qCqTG4Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Logical decoding fast-forward and slot advance (Petr Jelinek <petr.jelinek@2ndquadrant.com>) |
Ответы |
Re: Logical decoding fast-forward and slot advance
|
Список | pgsql-hackers |
On 31 December 2017 at 10:44, Petr Jelinek <petr.jelinek@2ndquadrant.com> wrote: > Attached is patch which adds ability to do fast-forwarding while > decoding. That means wal is consumed as fast as possible and changes are > not given to output plugin for sending. The implementation is less > invasive than I originally though it would be. Most of it is just > additional filter condition in places where we would normally filter out > changes because we don't yet have full snapshot. Looks good. The precise definition of "slot advance" or "fast forward" isn't documented in the patch. If we advance past everything, why is there not just one test in LogicalDecodingProcessRecord() to say if (ctx->fast_forward)? Why put it in multiple decoding subroutines? If ctx->fast_forward is set it might throw off other opps, so it would be useful to see some Asserts elsewhere to make sure we understand and avoid breakage. In pg_replication_slot_advance() the moveto variable is set to PG_GETARG_LSN(1) and then unconditionally overwritten before it is used for anything. Why? -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: