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. If the source communicated that to the replica, and
the replica held up application of any changes from T3 until T2 was
committed there would be no chance to read incorrect results. It
would not matter if T2 and T3 were committed on the replica
simultaneously or in AOoE, as long as the work of T3 does not
appear before the work of T2.
The replica does not need to send anything back to the source for
this to work.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company