Re: Logical decoding of sequence advances, part II

On Tue, Aug 23, 2016 at 9:36 AM, Kevin Grittner <kgrittn@gmail.com> wrote:
> On Tue, Aug 23, 2016 at 9:07 AM, Kevin Grittner <kgrittn@gmail.com> wrote:
>> On Tue, Aug 23, 2016 at 7:40 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
>>> On 23 Aug 2016 20:10, "Kevin Grittner" <kgrittn@gmail.com> wrote:
>>>>
>>>> On Mon, Aug 22, 2016 at 6:39 PM, Craig Ringer <craig@2ndquadrant.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.