On Mon, Aug 22, 2016 at 6:39 PM, Craig Ringer <cr...@2ndquadrant.com> wrote: > On 23 Aug 2016 05:43, "Kevin Grittner" <kgri...@gmail.com> wrote: >> On Mon, Aug 22, 2016 at 3:29 PM, Robert Haas <robertmh...@gmail.com> wrote: >> >>> it seems to me that >>> this is just one facet of a much more general problem: given two >>> transactions T1 and T2, the order of replay must match the order of >>> commit unless you can prove that there are no dependencies between >>> them. I don't see why it matters whether the operations are sequence >>> operations or data operations; it's just a question of whether they're >>> modifying the same "stuff".
>> The commit order is the simplest and safest *unless* there is a >> read-write anti-dependency a/k/a read-write dependency a/k/a >> rw-conflict: where a read from one transaction sees the "before" >> version of data modified by the other transaction. In such a case >> it is necessary for correct serializable transaction behavior for >> the transaction that read the "before" image to be replayed before >> the write it didn't see, regardless of commit order. If you're not >> trying to avoid serialization anomalies, it is less clear to me >> what is best. > > 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. -- 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
