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?
>>> ... 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
> 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
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.
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: