Re: Logical decoding restart problems

On 20 August 2016 at 00:36, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
wrote:

>
> Sorry, I have not saved trace with output of logical decoder. Bu t it
> really decodes just one update!
>

That's definitely a worry. Can you turn this into a reproducible, self
contained test case?

> DROP_REPLICATION_SLOT "mtm_slot_1";
> CREATE_REPLICATION_SLOT "mtm_slot_1" LOGICAL "multimaster";
> START_REPLICATION SLOT "mtm_slot_1" LOGICAL 0/0 ("startup_params_format"
> '1', "max_proto_version" '1', "min_proto_version" '1', "forward_changesets"
> '1', "mtm_replication_mode" 'recovered');
>

That'll make a new slot by looking for a recent/future non-overflowed
xl_running_xacts record to set as restart_lsn. Every xact that starts
_after_ that xl_running_xacts record will be decoded and replayed to the
client in its entirety. Every xact started before that xl_running_xacts
record, i.e. listed as running in the record, will not be replayed to the
client at all, whether it commits or rolls back, even though the commit
will be after the slot creation lsn.

> I have also tried to calculate last origin LSN for this node and
> explicitly specify it in START_REPLICATION.
>

That will have no effect because of the logic you pointed out around
confirmed_flush_lsn.

Dropping and re-creating the slot is the wrong thing to do if you want to
maintain consistency. Just advance it over the changes you already saw from
the other node. Read BDR's catchup mode code.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services