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
You appear to be saying that SSI allows transactions to commit in a
Do you have a test case?
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services