On 24 August 2016 at 00:26, Kevin Grittner <kgri...@gmail.com> wrote:
> On Tue, Aug 23, 2016 at 9:36 AM, Kevin Grittner <kgri...@gmail.com> wrote: > > On Tue, Aug 23, 2016 at 9:07 AM, Kevin Grittner <kgri...@gmail.com> > wrote: > >> On Tue, Aug 23, 2016 at 7:40 AM, Craig Ringer <cr...@2ndquadrant.com> > wrote: > >>> On 23 Aug 2016 20:10, "Kevin Grittner" <kgri...@gmail.com> wrote: > >>>> > >>>> On Mon, Aug 22, 2016 at 6:39 PM, Craig Ringer <cr...@2ndquadrant.com> > >> > >>>>> 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. > >>> > >>> Right. But we don't attempt to replicate locking let alone SSI state. > As I > >>> said this is expected. If T1, T2 and T3 run in the master in either > READ > >>> COMMITTED or SERIALIZABLE we will correctly replay whatever got > committed > >>> and leave the replica in the same state as the master. > >> > >> Eventually. Between the commit of T3 and T2 a state can be seen on > >> the replica which would not have been allowed on the source. > >> > >>> It is row level replication so there is no simple way to detect this > >>> anomaly. > >> > >> That is probably true, but there is a way to *prevent* it. > >> > >>> We would have to send a lot of co-ordination data *in both > >>> directions*, right? > >> > >> No. The source has all the information about both commit order and > >> read-write dependencies, and could produce a stream of transaction > >> IDs to specify the safe order for applying transactions to prevent > >> the anomaly from appearing on the replica. In this case the commit > >> order is T1->T3->T2, but the apparent order of execution (AOoE) is > >> T1->T2->T3. > > > > Sorry, trying to keep this conversation going while doing something > > else and sent a response there which doesn't really make sense, > > since the issue is whether to allow T3 to run *on the replica*. > > I'll take another look when I'm less distracted. You may be right. > > I had the right idea, but messed up the details. The source has > commit order T2->T1 and AOoE T1->T2. So as long as making any work > from T2 visible is held up until at least the point where the work > of T1 is visible, T3 on the replica cannot see an anomalous state. > > It is still true that a one-way stream of information from the > primary to the replica regarding AOoE would be sufficient > communication. > Hm. That's really interesting. So we could achieve SSI-like properties for read-only xacts on a replica if we could defer xact decoding, or buffer the xact on the downstream and defer apply, based on SSI info from the upstream. That'd be pretty cool. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
