On Tue, Aug 23, 2016 at 11:50 AM, Andres Freund <andres@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 <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...
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
