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: http://www.postgresql.org/mailpref/pgsql-hackers
