On 2016-08-23 07:26:31 -0500, Kevin Grittner wrote:
> On Tue, Aug 23, 2016 at 7:10 AM, Kevin Grittner <kgrittn@gmail.com> wrote:
> > On Mon, Aug 22, 2016 at 6:39 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
>
> >> 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.
>
> I should, perhaps, have mentioned that the cases where this is are
> problem are "eventually consistent" -- it's a matter of being able
> to see a state that violates business rule invariants or where data
> which is "locked down" according to one part of the database is
> still changing. Such problems are prevented on a single database,
> but would not be prevented on a logical replica where transactions
> are applied in commit order. Given enough time, the replica would
> eventually settle into a state without the anomalies, similar to
> some other products with eventual consistency.
I've generally a bit of difficulty to see this as a significant problem
for logical rep, as long as hot-standby, and crash-recovery in general,
also has this problem...
