Re: Logical decoding fast-forward and slot advance

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Logical decoding fast-forward and slot advance
Date: 2018-01-08 07:02:06
Message-ID: CANP8+jKfPG_6PO=BAVS-1DJhWnitjCBT_VjwpqxhLY_qCqTG4Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 31 December 2017 at 10:44, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2018-01-08 07:04:51 Re: [HACKERS] Statement-level rollback
Previous Message Tom Lane 2018-01-08 05:56:21 Re: Parallel append plan instability/randomness