Re: Logical decoding of sequence advances, part II

On 24 August 2016 at 00:26, Kevin Grittner <kgrittn(at)gmail(dot)com> wrote:

> On Tue, Aug 23, 2016 at 9:36 AM, Kevin Grittner <kgrittn(at)gmail(dot)com> wrote:
> > On Tue, Aug 23, 2016 at 9:07 AM, Kevin Grittner <kgrittn(at)gmail(dot)com>
> wrote:
> >> On Tue, Aug 23, 2016 at 7:40 AM, Craig Ringer <craig(at)2ndquadrant(dot)com>
> wrote:
> >>> On 23 Aug 2016 20:10, "Kevin Grittner" <kgrittn(at)gmail(dot)com> wrote:
> >>>>
> >>>> On Mon, Aug 22, 2016 at 6:39 PM, Craig Ringer <craig(at)2ndquadrant(dot)com>
> >>
> >>>>> Could you provide an example of a case where xacts replayed in
> >>>>> commit order will produce incorrect results?
> >>>>
> >>>> https://wiki.postgresql.org/wiki/SSI#Deposit_Report
> >>>>
> >>>> ... where T3 is on the replication target.
> >>>
> >>> Right. But we don't attempt to replicate locking let alone SSI state.
> As I
> >>> said this is expected. If T1, T2 and T3 run in the master in either
> READ
> >>> COMMITTED or SERIALIZABLE we will correctly replay whatever got
> committed
> >>> and leave the replica in the same state as the master.
> >>
> >> Eventually. Between the commit of T3 and T2 a state can be seen on
> >> the replica which would not have been allowed on the source.
> >>
> >>> It is row level replication so there is no simple way to detect this
> >>> anomaly.
> >>
> >> That is probably true, but there is a way to *prevent* it.
> >>
> >>> We would have to send a lot of co-ordination data *in both
> >>> directions*, right?
> >>
> >> No. The source has all the information about both commit order and
> >> read-write dependencies, and could produce a stream of transaction
> >> IDs to specify the safe order for applying transactions to prevent
> >> the anomaly from appearing on the replica. In this case the commit
> >> order is T1->T3->T2, but the apparent order of execution (AOoE) is
> >> T1->T2->T3.
> >
> > Sorry, trying to keep this conversation going while doing something
> > else and sent a response there which doesn't really make sense,
> > since the issue is whether to allow T3 to run *on the replica*.
> > I'll take another look when I'm less distracted. You may be right.
>
> I had the right idea, but messed up the details. The source has
> commit order T2->T1 and AOoE T1->T2. So as long as making any work
> from T2 visible is held up until at least the point where the work
> of T1 is visible, T3 on the replica cannot see an anomalous state.
>
> It is still true that a one-way stream of information from the
> primary to the replica regarding AOoE would be sufficient
> communication.
>

Hm. That's really interesting. So we could achieve SSI-like properties
for read-only xacts on a replica if we could defer xact decoding, or buffer
the xact on the downstream and defer apply, based on SSI info from the
upstream. That'd be pretty cool.

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