Re: The plan for FDW-based sharding

On 26 February 2016 at 22:48, Kevin Grittner <kgrittn(at)gmail(dot)com> wrote:

> On Fri, Feb 26, 2016 at 2:19 PM, Konstantin Knizhnik
> <k(dot)knizhnik(at)postgrespro(dot)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