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.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
