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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to