On 26 February 2016 at 22:48, Kevin Grittner <kgri...@gmail.com> wrote:
> On Fri, Feb 26, 2016 at 2:19 PM, Konstantin Knizhnik > <k.knizh...@postgrespro.ru> wrote: > > > pg_tsdtm is based on another approach: it is using system time > > as CSN > > Which brings up an interesting point, if we want logical > replication to be free of serialization anomalies for those using > serializable transactions, we need to support applying transactions > in an order which may not be the same as commit order -- CSN (as > such) would be the wrong thing. If serializable transaction 1 (T1) > modifies a row and concurrent serializable transaction 2 (T2) reads > the old version of the row, and modifies something based on that, > T2 must be applied to a logical replica first even if T1 commits > before it; otherwise the logical replica could see a state not > consistent with business rules and which could not have been seen > (due to SSI) on the source database. How would SSI allow that commit order? Surely there is a read-write dependency that would cause T2 to be aborted? > Any DTM API which does not > support some mechanism to rearrange the order of transactions from > commit order to some other order (based on, for example, read-write > dependencies) is not complete. If it does support that, it gives > us a way forward for presenting consistent data on logical > replicas. > You appear to be saying that SSI allows transactions to commit in a non-serializable order. Do you have a test case? -- Simon Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
