On Feb 6, 2014, at 8:44 AM, Alex Yurchenko <email address hidden> wrote:
> 1) causal wait is part of trans_begin() method, so you can always
> establish a proper read view. The fact that trans_begin() is not called
> on autocommit writes suggests (to me) that there are reasons why
> autocommit writes are supposed to be treated somewhat differently.
Hum, I thought causal_reads were literally just finding all SELECTs. Are you saying causal_reads are always in effect for explicit transactions? With or without wsrep_causal_reads=1?
>
> 2) we would rather rely on certification to detect a conflict/out-of-
> date write, rather than on dumb wait.
> The problem comes out of late
> INSERTS - if you don't have a row, you can't detect a conflict (we don't
> even have anything to replicate, since the write was ineffective). As
> such it touches only UPDATEs and DELETEs. (INSERTs a) can be resolved by
> certificaiton, b) it is very unlikely use case that you will be
> inserting the same PK because of stale data (only if you have auto
> increment control turned off))
>
> - the latter consideration brings us to an interesting point: we need a
> mask to specify events that we want to do causal wait. Perhaps we should
> introduce
>
> wsrep_causal_wait = <mask> (1 - SELECT, SHOW, BEGIN, 2 - UPDATE/DELETE,
> 4 - INSERT)
>
> wsrep_causal_reads=ON would be equivalent to wsrep_causal_wait=1
So was SHOW and BEGIN (and I assume START TRANSACTION) always part of causal_reads? Why SHOW?
Any command in autocommit=0 will start a transaction I think — would that be covered by wsrep_causal_wait=1? The extra masks are only for autocommit=1?
On Feb 6, 2014, at 8:44 AM, Alex Yurchenko <email address hidden> wrote:
> 1) causal wait is part of trans_begin() method, so you can always
> establish a proper read view. The fact that trans_begin() is not called
> on autocommit writes suggests (to me) that there are reasons why
> autocommit writes are supposed to be treated somewhat differently.
Hum, I thought causal_reads were literally just finding all SELECTs. Are you saying causal_reads are always in effect for explicit transactions? With or without wsrep_causal_ reads=1?
>
> 2) we would rather rely on certification to detect a conflict/out-of-
> date write, rather than on dumb wait.
> The problem comes out of late reads=ON would be equivalent to wsrep_causal_wait=1
> INSERTS - if you don't have a row, you can't detect a conflict (we don't
> even have anything to replicate, since the write was ineffective). As
> such it touches only UPDATEs and DELETEs. (INSERTs a) can be resolved by
> certificaiton, b) it is very unlikely use case that you will be
> inserting the same PK because of stale data (only if you have auto
> increment control turned off))
>
> - the latter consideration brings us to an interesting point: we need a
> mask to specify events that we want to do causal wait. Perhaps we should
> introduce
>
> wsrep_causal_wait = <mask> (1 - SELECT, SHOW, BEGIN, 2 - UPDATE/DELETE,
> 4 - INSERT)
>
> wsrep_causal_
So was SHOW and BEGIN (and I assume START TRANSACTION) always part of causal_reads? Why SHOW?
Any command in autocommit=0 will start a transaction I think — would that be covered by wsrep_causal_ wait=1? The extra masks are only for autocommit=1?
Jay Janssen about.me/ jay.janssen
http://