On Tue, Aug 23, 2016 at 11:50 AM, Andres Freund <and...@anarazel.de> wrote: > On 2016-08-23 07:26:31 -0500, Kevin Grittner wrote: >> On Tue, Aug 23, 2016 at 7:10 AM, Kevin Grittner <kgri...@gmail.com> wrote: >> > On Mon, Aug 22, 2016 at 6:39 PM, Craig Ringer <cr...@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...
Serialization anomalies cannot be seen on a hot standby nor on crash recovery. Granted, the mechanism which prevents it on the hot standby is that we don't allow the transaction isolation level to be set to SERIALIZABLE, to prevent the expectation that queries will be free of anomalies, which is pretty crude. On crash recovery you cannot see any anomalies as far as I'm aware -- what has given you the idea that it is possible? I'm not sure that the same technique I described for logical replication could be made to work for page-level physical replication, but a "safe snapshot" technique has been previously discussed on the lists which would work for physical replication (although *that* technique seems unsuited to logical replication). -- 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
