Re: Logical decoding of sequence advances, part II - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Logical decoding of sequence advances, part II
Date
Msg-id CACjxUsMGbKqsHHT-pZi4ogV=BJUa+uaPRoY_R80U-bYT9BAuOQ@mail.gmail.com
Whole thread Raw
In response to Re: Logical decoding of sequence advances, part II  (Kevin Grittner <kgrittn@gmail.com>)
Responses Re: Logical decoding of sequence advances, part II
List pgsql-hackers
On Tue, Aug 23, 2016 at 9:36 AM, Kevin Grittner <kgrittn@gmail.com> wrote:
> On Tue, Aug 23, 2016 at 9:07 AM, Kevin Grittner <kgrittn@gmail.com> wrote:
>> On Tue, Aug 23, 2016 at 7:40 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
>>> On 23 Aug 2016 20:10, "Kevin Grittner" <kgrittn@gmail.com> wrote:
>>>>
>>>> On Mon, Aug 22, 2016 at 6:39 PM, Craig Ringer <craig@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.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Block level parallel vacuum WIP
Next
From: Robert Haas
Date:
Subject: Re: Question about MVCC-unsafe commands